How to avoid costly mistakes while buying custom software

Woman frustrated by costly mistakes

As providers of software development services, we encounter clients from a wide variety of backgrounds and industries.  All companies, from startups to mega corporations, have business problems that can be solved with technology solutions.  However, software development is a wildly complex skillset that is often made less comprehensible by ever-evolving jargon and practitioners who are only familiar with talking amongst other practitioners. This leads to a massive knowledge imbalance between buyers and sellers, which in turn opens the door for unskilled teams to take advantage of unsuspecting buyers.

Over the years we’ve heard countless stories of buyers having bad experiences with their software projects (in fact, we’ve helped fix a couple of those projects!).  Whether its buying software that isn’t needed, entering into unfavorable contracts, or simply not being aware of the expenses involved with a project until its too late, the buying process is filled with potential pitfalls that can affect the overall success of the project.

Because of this, we’ve decided to provide an educational guide for buyers.  This should not be considered a comprehensive checklist, but instead a starting point for further research.  Our goal is to help prepare you for what to expect, what to ask, and what you should know to avoid making costly mistakes.

What should you think about before starting the process?

Many potential buyers have not fully considered what building and owning a software system means. This is a big undertaking with big ramifications for your business. Take a few minutes to consider the following pitfalls and misconceptions that new buyers deal with.

Software is expensive

This is the number one thing that most people are surprised by when they first start looking into a software project.  The skills required to properly build a software application take many years of constant training and dedication to refine.  What further complicates this issue is the relatively low barrier to entry.  Virtually anyone can take a few free courses and call themselves a developer, and many people do.  As the market saturates with new, inexperienced developers, it leads buyers to assume that it’s an easy/common skill set that shouldn’t cost much.

Worse yet, lower skill developers typically focus on skills that produce visually appealing, user facing code, while not training on how to scale large applications.  This means that buyers often don’t realize their software is broken until they attempt to onboard users and their money is already gone.

 It can not be overstated how often we encounter buyers with broken code bases and empty budgets looking for a quick fix to system that is beyond saving.

While the lure of cheap developers is a powerful one, keep in mind that the vast majority of projects made by low skilled developers need to be scrapped.  While prices can vary wildly based on geographic location, a typical US based proof of concept project will run anywhere from $50,000-100,000. Hourly rates for talented on shore development firms will likely be anywhere from $110-185/hr, and potentially higher for teams that provide DevOps engineers and have enterprise software experience.  Talented developers are worth their weight in gold, and their salaries reflect that.

Think of software like building a skyscraper.  Low-cost developers have learned how to poor cement, place rebar, and decorate a pretty facade, but don’t have extensive training in large scale mechanical stresses, foundation design, and resource management.  The building will look fine for a while, but as it grows the cracks will show and eventually it will fail and need to be rebuilt.

Not all languages and frameworks are equal

Every development team has their favorite programming language and frameworks, and they will likely give you reasons why you should allow them to build with that language or framework.  While it’s true that most code behaves in roughly the same way, your job from a business perspective will be to support this application long term.  That means your project needs to be written in a language that is popular, and likely to be around for a while.  The developers may love a new fad language that’s just “so much better” than the older languages, but if the new language dies out in six months you now have to A) stick with that team forever, or B) find some other shop using this niche, probably expensive language.

We encourage you to research application languages and frameworks on your own, but this 2021 Stack Overflow survey is very helpful.

Your business needs should be defined

Think long and hard about what problem you’re solving and how much money you’re losing by not solving it.  You don’t have to know HOW software will fix the problem, that’s for the development team to figure out, but you do need to know WHAT problem you’re fixing and how much money that fix will save you over time. 

If the team doesn’t actively understand and work towards solving your business problem, get a new team.

On the flip side of this, understand that business problems have a lot of solutions, and the most appropriate solution may not involve the specific technology you have in mind.  Our team regularly encounters buyers who insist that they need an app yet describe a business problem that does not fit a mobile app delivery model.  The best project outcomes occur when business experts focus on business problems and technology experts focus on the best technology to solve those problems.

Software projects don’t end

This is another misconception that tends to blindside buyers.  Most people assume that a project will start on a specific date, run for a specific time, then end.  But the reality is that software expenditure ends when the problem no longer needs fixing.  At a minimum, the software will incur monthly hosting and maintenance costs.  You cannot leave modern software without maintenance because there are so many connections to other applications that any number of external factors can destabilize your system.  Your system will need to be actively monitored and fixed as errors occur.

However, errors aren’t the only things to consider.  Most projects end up identifying other business issues beyond those originally in scope. Virtually all businesses have an ever-increasing backlog of business problems to solve, each with a corresponding increase in revenue or decrease in expenses.

If the business problems are being solved properly, the economical solution is to continue development indefinitely.

You MUST be hands on

Custom software products are, by definition, creating solutions to non-standard problems.  If the problem were standard, there would already be a software product available to solve that problem. That means that the quality of your solution will depend entirely on how clearly and frequently you can communicate your business problem to the development team.  Nothing predicts negative project outcomes like buyers who are not willing to be involved with their custom solution. 

Think of it this way, if you had an idea for a brand-new car that doesn’t behave like any car in existence today, would you assume that you could describe it to engineers one time and then come back in a few months and have the perfect car? No, you would need to constantly discuss the new functionality you want and sign off on changing the functionality that may not be possible.

Common terminology all software buyers should know

Knowledge of common development terms can greatly increase your understanding of the project, as well as the competency of your potential development partner.  There are nearly endless development terms, but we’ve done our best to choose those that most apply to team’s ability to produce quality work.


Agile is a software development philosophy that focuses on iteration, quickly assessing new information, and changing directions as needed.  Methodologies that use Agile principles are proven to result in better project outcomes over a shorter timeframe.


This term is used to encompass a wide range of activities surrounding the successful operation of development teams.  DevOps is concerned with making sure code is deployed consistently, with minimal bugs, and with many contingencies to prevent system failures.  Robust DevOps practices are mandatory for large, enterprise applications.


In software development, the “environment” typically refers to an instance of the system that is set up for a specific purpose.  Environments allow the engineers to change specific variables for various stages of the development process.

Development Environment

This is where engineers modify and expand code.  Development environments are typically unstable due to large scale changes, and 3rd party integrations (particularly those that charge money) may be disabled.

Test Environment

This is a more stable version of the system where manual testing can happen.  It’s built to simulate what active users would see and is generally more stable than the development environment.  3rd party systems may be active at this stage to fully simulate the user experience.

Production Environment

This is the version of the system that users see and interact with.  It contains live data and outages are considered critical.  No changes should be made directly to this environment without first going through a review and testing process.


Scrum is one of the most popular methodologies that uses Agile principles.  In this methodology, the team commits to a set amount of work in fixed periods of time called “sprints”.  The work is then evaluated, and a new set of work is chosen for the next sprint based on the results of the previous one.

Version Control

Technology used to update the code base in a controlled and reversable way.  Code bases that are version controlled can easily be “rolled back” to a previous version if a mistake is made. Virtually all modern code repository tools will use some form of version control to protect the code base.

Automated Testing

Software systems are wildly complex and contain too much functionality to test manually.  To deal with this, engineers write small pieces of code that test the functionality of the code that comprises the system.  These tests run periodically and let the engineers know if any of the system code changed in a way that broke functionality.  When that happens, a report will tell the engineers where the failure happened which lets the system be fixed much faster.  Below are some examples of specific types of automated tests.

Unit Tests

Tests designed to validate that individual “units” of code still run properly.  For example, a unit test may validate “XYZ unit of code always generates an even number”.

Integration Tests

These tests ensure that large modules of functionally within the system behave properly when combined. For example, an integration test may validate “Module X and Module Y do not product errors when run together”.

End-To-End (e2e) Tests

These tests simulate a user in the system by testing functionality from the standpoint of the UI.  While these tests more accurately represent the real-world usage of the system, they are more expensive to build, slower to run, and more difficult to change. Because of this, engineers may choose to use them sparingly. An end-to-end test may validate “When the user clicks on X page element, the page navigates to Y page”.


A place where all the code in the application is stored and updated.  Typically, this is cloud hosted and accessible anywhere.


A sprint is the period of time in which a team will work on a set amount of work.  Sprints periods are anywhere from 1-4 weeks, however 1-2 week sprints are generally considered the most productive.

Test Driven Development (TDD)

Test driven development is a coding practice in which engineers write the automated tests before writing the functionality.  As the functionality is being written, the automated tests will continually tell the engineer if the new code is correct.  This is generally considered a more advanced technique but results in extremely well written and tested code.


The way in which individual lines of code are written. Similar to traditional human languages.

Continuous Integration and Continuous Development (CI/CD)

CI/CD is a series of automations and activities designed to move new pieces of functionality through a “pipeline” of validation and testing before ultimately being deployed for users to experience.  The CI/CD process is one of the primary concerns of a DevOps practitioner.


A collection of pre-build functionality, written in a specific language, that encourages developers to build a system using known patterns.  For example, applications using the Angular framework are written in the Typescript language.  The Angular framework provides pre-built tools, written in Typescript, that only work properly if used the way the Angular framework developers intend for them to be used.  Frameworks allow teams to move much faster, but occasionally present development challenges if the project calls for functionality that the framework does not support.


All systems experience errors, regardless of how much automated testing is done.  When these errors happen in production the system needs a way of reporting what went wrong, when it went wrong, and who was affected to the development team.  Monitoring software is installed within the system code to generate these reports and send out alerts when critical errors happen.

Tech Stack

The “stack” refers to the collection of technology used in each of the layers of the application. An example of a tech stack would be “Angular, .NET Core, and SQL” which means that the front end of the application would be written in Angular, the API/middle layer would use the .NET Core framework, and the database would be a SQL database.

Front End Layer

The “front end” refers to the technology used to produce the part of the system the user sees and interacts with.  This can refer to website tech or mobile app tech. 

Middle Layer

The middle layer or middle tier is the part of the application that acts as the “brain” of the system.  It makes decisions about what information is sent to the front end, how information is transformed, and what information is sent to the database.

Storage Layer

This layer houses data long term.  When a user makes a request via the front end, the middle layer interprets this request and retrieves data from this layer.

Key questions for potential partners

Questions are an absolutely vital part of the process. With the success of your project riding on both parties understanding of each other’s needs and capabilities, the only “bad” question is the one not asked. We’ve provided some example questions to get a feel for your partner’s capabilities, but we encourage you to think of more and ask away.

“Will I have access to the team’s planning tools?”

Teams should be using some sort of centralized place for organizing the current work (essentially a group TO DO list), and you should have access to it.  You are paying a lot of money and you deserve to have work visible to you.

“How will I check the quality of the work during development?”

Again, work needs to be visible.  If you do not have a way to test or view the system than you cannot confirm that the correct work is being done.  Rewrites are expensive.  Its your job to provide rapid and frequent feedback, and it’s the development team’s job to make it easy for you to see your system.   Most firms should create a test environment for you to play around with as the system is built.

“Will I have access to the repository?”

Its your code.  You paid for it, you own it, and you should have access to it.  Larger, more established firms may simply write into the contract that you own all the code and provide access as needed.  However, if you’re dealing with freelance engineers, or otherwise less established businesses, always ask for admin access to the repository so that you can remove users and retain your code.

“Who owns the IP of the code generated, and is it specified in the contract?”

This is a highly complex issue that will likely require further research on your part.  However, in general you will want to make sure that the code used in your system is either written by your team or open source and legal to use free of charge.  You will also need to make sure that all code written by your development team is completely and totally owned by you forever.

“What is your preferred tech stack?”

They should be able to answer what their preference is, as well as if they’re able to use other technology beyond their favorites. Do your research on the technologies they use and try to avoid niche languages and frameworks that may hurt you in the future.

“What is your automated testing process like?”

At a minimum they should use unit tests and LOTS of them.  The more they can speak on testing the better.  Companies that use unit, integration, and end to end testing while practicing test driven development will likely produce extremely high-quality code but will be more expensive than other companies.  In general, automated testing slows development up front, but saves huge amounts of money long term.  If your project is quick and not very complex, you’ll likely be ok without much automated testing.  If you intend to build large, enterprise system, testing is a must, and your development partner needs to be capable of building those tests.

“What is your CI/CD process like?”

Ideally the process will involve a test or staging environment that is not public.  Releases should be frequent and automated tests should run as part of this process.  This process should also provide a quick way to revert back to previous versions of the system in the event of a critical error making it into the production code.

“What is your work methodology?”

Good processes are arguably one of the most important determining factors in the success of a team.  If a development partner cannot accurately describe the process by which the team completes work, you can bet that development will be slow and poor quality.  Amongst defined development methodologies, Agile centric methodologies have been proven to be the most effective as they promote strong communication, frequent evaluation, and rapid adaptation to new requirements.   

Did you get all that?

This is a massive topic and unfortunately this ridiculously long blog post doesn’t even scratch the surface. However, we hope that this information was thought provoking enough to serve as a starting point on your journey, and to help you feel more confident and more capable of working with a team.

At Sigao our mission has always, and will always, be to leave our partners better off than before they met us. If you have any questions about this topic, feel free to comment below or give us a shout directly.

6 Potent Power Patterns Every Scrum Master Can Use Today

Great Scrum Masters understand team development and intentionally coach and improve their team’s performance over time. A Scrum Master can equip Team Members with helpful tools and best practices by learning and using power patterns.

Power Patterns help the Scrum Master build happier teams that can work more efficiently, remain stable over time, and continue developing and expanding their skillsets. Power patterns should be incorporated throughout the Sprint and reaffirmed frequently.

If you are unfamiliar with power patterns, we’ve selected 10 essentials to illustrate the importance of coaching and development within a Scrum Team.

Happy teams are better performers over time

Most would agree that an engaged worker is more productive and generally better for the team and organization as a whole.

Less discussed is the subtle link between engagement and happiness that exists within individual team members. However, this is an important discussion because the happiest employees also tend to be the most loyal and engaged.

In Scrum, The Scrum Master should be intentional about measuring, analyzing, and improving happiness amongst the team even though it is difficult to attribute an increase in happiness to one specific change. Instead, the Scrum Team’s working agreement, communication, and activities are constantly iterating over time to increase this metric.

Quantum entanglement means forming a bond among team members

An interesting quirk of quantum physics is that it is possible to link together two particles to essentially make the two parts of the same whole. Once complete, these particles can be separated far apart, and still, one change will instantly reflect on the other.

In Scrum, we talk about quantum entanglement in the context of forming bonds with team members. Practically speaking, this means teams should work collocated as much as possible, especially in the beginning.

This power pattern has become more relevant than ever today as many teams find themselves working remotely, either temporarily or permanently. Without face-to-face meetings, it can be difficult for individual team members to form close bonds. In cases where some team members work remotely while others are collocated, negative ‘us and them’ behavior can develop.

To address this issue, consider following this three-step process when creating teams or adding team members to an existing team:

  • Initialize – establish a bond by encouraging team members to work together locally
  • Inspecting – The Scrum Master should intentionally watch for signs of team degradation and dysfunction
  • Adapting – If dysfunction is found, work should be done to repair the damage and reestablish face-to-face working experiences.

Stable teams provide more predictable results

Scrum Teams should be autonomous, empowered, and dynamically changing to meet the demands of the product they are creating.

At the team level, dynamic change can cause volatility in performance during the short term but will lead to stronger, more predictable performance increases over time. As a result, Scrum Teams thrive when they are kept small and stable because they can capitalize on the long-term benefits of doing good Scrum over time.

These stable teams tend to communicate better, work more efficiently, and continue to improve their performance over time incrementally.

At the organizational level, predictable results and reasonable expectations about the future allow leadership to make better decisions and achieve greater success.

Swarming helps complete PBIs more efficiently

The best Scrum Teams can prioritize working on one Product Backlog Item at a time as a team in a process known as ‘swarming.’

Swarming helps minimize the amount of work in progress by allowing the team to be creative as a group during production while also reinforcing the necessity of testing the product before moving on to another task. This behavior also helps teams avoid the compounding negative effect of task switching and multitasking.

As a best practice, allow one team member to take the lead on each PBI – everyone on the team must then help the leader complete the work until it is finished. Once complete, a new team member can take the lead on the next task.

Teams that finish early accelerate fast

The Scrum framework exists to help improve performance over time, and much of that work involves addressing the negative tendencies that many teams develop.

One such negative tendency among Scrum Teams is that they simply take too much work into their Sprint and cannot finish it. While occasional failure is expected and even healthy in some cases, frequent failure is demoralizing and leads to inconsistent or low performance over time.

Teams should focus on finishing a smaller amount of work early rather than a larger amount just in time to combat this issue. Extra time within the Sprint can sharpen skills amongst team members, pay down technical debt, and generally create opportunities for work multipliers to develop.

Fortunately, using Yesterday’s Weather and a powerful system for handling Interrupts helps keep the Scrum Team honest about their capabilities, allows them to celebrate successes, and contributes to faster acceleration over time.

Emergency procedures salvage work from a failed Sprint

Although the term ’emergency procedure’ sounds more appropriate for a fighter jet manual or a plant’s safety department, any team doing important work needs a system in place to protect them when things go wrong.

In Scrum, the Emergency Procedure Power Pattern exists to salvage a Sprint that is unable to be completed successfully due to the following reasons (or something else entirely):

  • A loss of personnel or equipment
  • Technical issues
  • Emergent and unavoidable interruptions
  • Overestimated work capacity
  • Underestimated work

Despite their best efforts, any one of these issues could cause a team to fail a Sprint. When the team realizes that the current Sprint cannot be completed, they should ‘push the red button’ and activate their emergency procedure.

Importantly, anyone on the team should feel capable of pushing this button and having a conversation as a team.

Typically, a Scrum Emergency Procedure will include:

  • Doing something different – changing the way the team does work or who is doing the work
  • Getting help – offloading backlog items to another team or accepting external help
  • Reducing the Sprint Goal to exclude a portion of the accepted work
  • Aborting the Sprint completely and replanning
  • Discussing the issue with management and stakeholders

Agile Toolkit: A Free Tool To Help Scrum Masters Manage Sprints

Veteran and novice Scrum Masters, alike, can struggle with finding a practical tool to help manage their Sprints on a weekly basis.

Our free Agile Toolkit is an easy-to-use and highly functional Excel sheet that allows Scrum Masters to manage their Sprint more effectively. This tool handles tracks Team capacity, velocity, Yesterday’s Weather, Interrupt Buffers, and more! It also generates charts for a team’s velocity over time and individual Sprint burndowns.

Regardless if you are starting from Sprint zero or need a new solution for your established team, this tool will be a great fit!

To grab the tool and get started, head over HERE to sign up. You’ll also get access to a video demonstration and tutorial to help get you started!

Why is the Agile Toolkit so useful?

Don’t forget that while the Product Owner is responsible for WHAT the team does the Scrum Master is focused on HOW the work is getting done and a big part of the ‘How’ revolves around the Sprint itself.

Fortunately, the Agile Toolkit handles a LOT of Sprint-related tasks!

Before the team can even start Sprint Planning, the Scrum Master is responsible for gathering team capacity, calculating Yesterday’s Weather and the Interrupt Buffer, and letting the Product Owner know how many points they can accept into the upcoming Sprint.

Once the Sprint starts, the Scrum should also be constantly updating the Sprint Burndown to ensure that work in progress is being completed in a timely fashion and helping the team decide how to handle any interrupts.

After the Sprint is complete, the Scrum Master will get to work updating the team’s velocity, gathering data on the team’s happiness, and preparing to lead the Sprint Retrospective.

So go ahead and download the toolkit and get started HERE!

Women in Tech: A Snapshot of Birmingham, AL

Times they are a-changin’ but there’s still a lot of work to do.

Setting aside the broader issues of workplace inequality, today we want to focus on a slice of the marketplace that we are more familiar with here at Sigao Studios – the tech world. As March is Women’s History Month we decided to take a quick snapshot of the state of women working (or attempting to work) within tech fields and their most common challenges.

In addition, we we want to take the opportunity to highlight our local Birmingham, AL tech community and some of the amazing women that are leading the way for change to happen.

Challenges that women face entering the tech industry

It’s no secret that women have had to deal with a myriad of work-related issues throughout modern history, including outright legal obstacles standing in the way of progress.

While the number of barriers has been dropping dramatically in recent years, the playing field is by no means level.

In fact, according to a 2018 report, women held only 25% of all of the jobs within the tech industry despite the fact that they made up nearly half of the total workforce. Alarmingly, this percentage is actually LOWER than it was back in the 1980s.

The reasons are complicated and varied but one thing we do know is that the disparity starts all the way back in grade school as only 64% of girls opt for STEM subjects when given the chance compared to 83% of boys. This gap holds true at the university level as well dropping to 30% and 52% for girls and boys, respectively.

A logical and often-cited answer is that young girls (and later women) simply aren’t as interested in STEM-related subjects but it masks the fact that there are many gender-related stereotypes and institutional traditions that work to erase that interest before it even appears.

Let’s take a look at the 4 most common issues facing women in tech, according to a recent report on the state of women in tech and see which are getting better and which are getting worse.

Being taken seriously due to outdated gender perceptions

According to the date in the survey, the most serious issue for women interested in entering a tech industry is that they aren’t taken seriously by their peers and supervisors.

In fact, 53.8% of women reported this challenge in 2019. Fortunately, this number is down from 63% in 2018 so this is a trend that appears to be getting better over time.

Gender-based pay gaps

Gaps in pay associated with gender-based discrimination or other concerns have been discussed within the workforce as a whole for many years.

In fact, 63.7% of women stated that ‘equal pay and benefits’ was the primary factor in their ideal job in tech.

Although the gap has been shrinking overall, there are many signs that the gap in certain tech-related fields is narrowing faster than average – Scrum Master being one of them! In fact, it was recently reported that although the number of women employed as a Scrum Master in 2019 was lower than men, a larger percentage of them fell in the higher-income bracket of $75,000-$149,999 USD.

If you are interested in learning more about what a Scrum Master is and whether or not it makes sense for you, head here!

The glass ceiling

While trends have looked better so far, one area that regressed within the last couple of years concerns the ‘glass ceiling’ phenomenon in which many women feel as though there is an invisible barrier preventing them from rising past a certain level within a company.

In fact, 27.1% more women felt as though the glass ceiling existed in 2019 compared to 2018.

Because the upper echelons of power within companies has traditionally been ruled by men, it is remarkably easy for a ‘boys club’ mentality to take root and stifle the aspirations of upwardly mobile women looking to make the jump into the C-suite.

Fortunately, it is easier now than ever for women to start their own companies to completely bypass this challenge and create their own possibilities.

Having no female role models

Given the male-dominated history of tech role models throughout history it should come as no surprise that young girls (and later women) have had a hard time finding a female role model in the tech world to aspire to.

In fact, only relatively recently has the number of high-profile women in positions of leadership in the tech community grown to include role models with which young women could identify with and attempt to walk in their footsteps.

In 2019 Susan Wojcicki, CEO of YouTube, was voted the most influential woman in tech accounting to a poll in The Times.

Since YouTube is the second most trafficked website in the world right now, at 4.06 billion visits per month, she should certainly be a big deal to young girls thinking about their future.

Birmingham, AL organizations making a difference in the community

Fortunately, we don’t have to look far in Birmingham to see signs of change and progress happening around us.

Really, there are too many examples to list in this article but we wanted to at least bring attention to a few organizations and individuals that Sigao has worked closely with over the past couple of years to celebrate their work!


One of our favorite people in Birmingham is Carmen Mays and while she is involved in many amazing organizations, she is perhaps best known for leading her own company – Elevators.

Elevators’ mission is simple: to work alongside communities to build equitable entrepreneurial ecosystems by focusing on Creatives of Color.

Check out what she is up to here!

Birmingham Black Techies

Fresh off of the amazing Black Tech Takeover community event, Niesha White has been making moves with her own organization – Birmingham Black Techies.

“Birmingham Black Techies is for every Black person who’s been to a tech event & felt out of place. We’re here to answer your questions, share job resources, and bring visibility to Black people in tech. This is a supportive community, a place for you to meet other techies, have fun, and learn something tech-related along the way.”

Check out news and upcoming events here!


Another amazing organization within Birmingham works specifically to match the “hidden” talent pool of women that would traditionally be forced out of the workforce due to less flexibility in scheduling to companies that can benefit from their expertise and experience on their terms – fast.

Lead by CEO and Founder Delphine Carter, Boulo has been extremely successful in their mission during their first few years in business.

Check out what they are up to here!

Black Girl Ventures

Black Girl Ventures knew that Birmingham was a special place when they opened their local chapter here. Positioned as the largest pitch competition globally for Black/Brown women founders, BGV represents an amazing opportunity for early-stage entrepreneurs to get funding to scale their business.

Two of the women involved with the Birmingham chapter are even Sigao Studios training alumni! Both Jaclynn Hudson and Carmen Mays (there she is again!) have gone through our dual-certification Scrum Master and Product Owner classes and we absolutely love them!

Check out what they are up to here!

A bright future

Although the past is dark and the present can seem dim we know that there is a bright future ahead for all women that choose to either pursue a career in tech or start their own tech-focused businesses.

At Sigao, we stand with the women of our community and across the globe and pledge to offer any support that we are able to provide.

One example of this support is our current partnership with NCWIT to provide full scholarships to our Dual-Certification Scrum Master and Product Owner bootcamps. These scholarships have already allowed many women to take the next step on their Agile journey at no cost!

Find out more information about this and other scholarships that you might be eligible for here.

Scrum@Scale: An Overview of the Framework

These days, most people know and understand Scrum as a framework that helps people, teams, and organizations generate increasing value over time by creating an environment that allows them to work on the right thing in the right away.

At the individual team level, Scrum has demonstrated time and time again that it can help produce twice the work in half the time.

While seeing these results at the micro-level is exciting, scaling these results across an entire large organization is a truly spectacular event that can be produced by introducing Scrum@Scale.

What is Scrum@Scale?

If the individual Scrum team is a chapter then Scrum@Scale is the book.

Describing Scrum@Scale as simply deploying Scrum at the organizational level – replacing traditional departments and business units with Scrum teams – would be a disservice to what is ultimately a transformational catalyst that unlocks the full potential of a company’s collaboration and productivity.

Scrum@Scale allows the hyper-productive, results-driven performance of an individual Scrum team to scale across an entire organization to coordinate around and solve complicated problems at the Enterprise level.

Yes, Scrum@Scale creates more Scrum teams within an organization. But, it also:

  • Addresses complex adaptive problems within the organization
  • Delivers products more creatively
  • Can be applied across a myriad of industries including services, software, hardware, operations, and research

Who uses Scrum@Scale?

Although Scrum and other Agile methodologies have their roots within the software and IT communities, there are a staggering number of businesses using Scrum and Scrum@Scale to become more successful over time.

In fact, there are many case studies available that show exactly how effective Scrum@Scale can be within organizations.

Manufacturing and engineering: Bosch

Bosch, a giant multinational conglomerate of 390,000 employees, found initial success when they implemented Scrum within certain silos of the organization.

Recognizing the powerful results, they decided to implement a company-wide Agile transformation from the top down using the Scrum@Scale framework. Rather than silos, the company was divided into business units composed of cross-functional teams that were each capable of creating innovative new products and services.

The results?

Bosch cut its development time in half, allowing them to innovate faster and bring new products to market in record time.

Full case study here.

Insurance Industry: Insure-Tech

Insure-tech, an established company centered around finding ways to create more savings and efficiency within the current insurance industry recently found themselves surrounded by a wide variety of new, small, and aggressive companies attacking their market share.

By implementing Scrum@Scale, Insure-tech was able to improve customer satisfaction by 37%, increase dev team overall happiness by 34%, and reduce the number of product defects by 15%.

All within two months.

Full case study here.

Scrum@Scale training

While creating a Scrum team within an organization requires training at the individual level – Scrum Team Members, Scrum Masters, and Product Owners, Scrum@Scale requires implementing changes at the organizational level.

By creating an intentional Agile transformation, Scrum@Scale positions a company to provide more autonomy to highly-engaged, empowered teams.

What’s the best way to get started with this transformation?

Scrum@Scale Foundations

The Foundations class is an interactive workshop that provides professionals at any level of Scrum proficiency the lean principles and core concepts of scaling Scrum within an organization.

Whether your business has already implemented Scrum in some way or not, the Scrum@Scale Foundations class is the perfect way to provide basic training to an entire organization, at a low cost, before taking the next step of the Agile transformation.

You will understand:

  • That traditional ways of working in silos slow us down and make it hard to efficiently build our business and serve our customers. They make a paradigm shift in their view of efficiency and understand this is really about effectiveness.
  • How Scrum@Scale can impact their organization. They are able to identify and understand the main components of the Scrum@Scale framework, including the scaled roles and events.
  • That becoming a Scrum@Scale Practitioner and obtaining further, robust experience with Scrum@Scale will help their organization remain sustainable.

Sigao Studios is currently offering Scrum@Scale Foundations virtual classes which you can learn more about here.

Scrum@Scale Practitioner

The Practitioner course is designed to equip people within an organization, from team members to executives, with the knowledge and tools necessary to implement Scrum at the any-size level.

Class material covers the responsibilities of the Product Owner, Scrum Master, Scrum Team, and enterprise leadership in a variety of contexts and business situations.

You will learn how to:

  • Understand how restructuring an organization around scaled Scrum can create an incredible impact on performance.
  • Break down cross-team dependencies and create the ability to prioritize work across multiple teams towards company-wide initiatives.
  • Observe, analyze, and improve key metrics of Enterprise agility.
  • Create a transformation roadmap for your organization that includes a backlog of critical activities.

Note: It is recommended that Scrum@Scale Practitioner attendees have prior experience with Scrum including Scrum Master and Product Owner coursework or comparable real-world application.

Sigao Studios is currently offering Scrum@Scale Practitioner virtual classes which you can learn more about here.

Taking Action

Now that you understand what Scrum@Scale is and how it can benefit you and your organization it is time to act and start the transformation.

Allow Scrum@Scale to create the change you want to see within your business and let us use our real-world business and classroom experience to show you how.

Scrum Holiday Gift Guide 2020

Happy Holidays from the team at Sigao Studios!

If you are still looking for a few gifts for friends and family (or yourself!) we wanted to make sure that you don’t have to look far for some great Scrum and Agile-related ideas.

Since we love learning about Scrum at Sigao, our first list is a reading list!

Our CEO, Chris Sims, has curated a fantastic list of books that cover everything from the basics of Scrum all the way up to leading Agile teams and preparing your business for its next pivot!

By the way, we also have lots of opportunities for FULL scholarships to our Dual-Certification Scrum Master and Product Owner Virtual classes. If you want to learn more about that, head to our class page right here!

Reading List: 

New Year’s is just around the corner – are you prepared to make 2021 your best year ever?

This list will help you learn more about Scrum and what it can do for your business, better understand how to put those ideas into practice within your organization, and even how to coach your employees.

Techy Gifts: 

If you aren’t in the mood for a book, don’t worry, because we have a sweet list of geeky stuff to check out too and the best part is that the first four items are from local Birmingham tech companies!

Some of these gifts ideas are super functional while others are just interested in fun!

Scrum Guide Changes in 2020 (What’s New?)

On November 18th, the 2020 updates to the Scrum Guide were released by Jeff Sutherland of Scrum Inc. and Ken Schwaber of that include changes to the way Scrum is defined and implemented, so we would like to provide a rundown of these changes and how it might impact your Scrum Team.

The 2020 Scrum Guide has been updated with simplified language to be less prescriptive and more focused on self-managed, unified teams. There is a new Sprint Planning topic, “Why,” and the three artifacts all received new commitments (Product Goal for the Product Backlog, Sprint Goal for the Sprint Backlog, and Definition of Done for the Increment).

Although the language and implementation have been streamlined and simplified, there are still many changes that active Scrum Teams will need to understand to update their own processes. Let’s go over the changes.

What changed in the 2020 Scrum Guide

While significant, it is important to understand that the changes to the Scrum Guide in 2020 do not deviate from the core principles of Scrum.

Rather, these changes are meant to standardize certain trends within the Scrum community, build upon Scrum’s rampant success within organizations, and make it more approachable for businesses that sit outside the IT-related fields that Scrum has historically dominated.

If we had to pick an overarching theme for the 2020 Scrum Guide update, it would be simplicity. More simplified language, more clarity around purpose, and fewer obstacles in the way of implementation.

Let’s check out the main changes to the Scrum Guide in 2020.

Less prescriptive than before

Scrum has always been a methodology rather than a structured system.

In fact, that’s part of the beauty of Scrum – it is an outline for a process that any business can use to both make better decisions about what they are working on and constantly improve how they are doing it.

Unfortunately, it has seemed in recent years that Scrum has gotten more prescriptive rather than less so.

With this update, however, Scrum is dialing back specific instruction in favor of providing a minimally sufficient framework that can be more easily adapted to fit the needs of new and different businesses.

Here are the most notable changes in this area:

  • Removed Daily Scrum questions
  • PBI attributes are handled more loosely
  • Retro items in the Sprint Backlog are handled more loosely
  • Fewer rules around Sprint cancellation

Resetting the team mindset – one team, one product

Scrum has always focused on empowered, self-organizing Scrum Teams to produce the best work possible.

Sometimes, however, the goals of the Product Owner and Developers can diverge and create a division within the Scrum Team. This ‘us vs. them’ mentality prevents the team from working on the right thing and causes them to do poorer work at the same time.

The 2020 Scrum Guide realigns the team’s effort around a new concept – the Product Goal – to help mitigate the divisiveness between the PO, SM, and Developers.

The new Product Goal

The best way to allow a team to focus on the same goal is to push it out far enough that everyone can see it.

With the introduction of the Product Goal, the entire Scrum Team can focus on a large, valuable objective in the distance and the primary mission of each Sprint becomes bringing the product one step closer to the Product Goal.

The benefit of this approach is that it shifts the focus away from the smaller details of a project and forces alignment around a larger vision.

The new Artifact commitments

Over the years, many terms and ideas central to the Scrum framework have been implemented despite the fact that they haven’t been formally defined.

Two examples of this are the Sprint Goal and the Definition of Done.

Although the Sprint Goal and Definition of Done are not new, the Scrum Guide has been updated to give them, along with the new Product Goal, a stronger identity within the Scrum framework by transforming them into commitments for the three artifacts.

Here is how they match up with the artifacts:

  • Product Backlog – Product Goal
  • Sprint Backlog – Sprint Goal
  • Increment – Definition of Done

By linking these ideas together more tightly, they provide more transparency and focus toward each artifact’s progress.

Self-managing vs. self-organizing

Scrum has always relied on the value that self-organized and empowered teams can provide to an organization.

In fact, it’s been demonstrated time and time again that teams perform better when they can choose who is doing the work and the best way to get it done.

With the 2020 update, the Scrum Guide takes self-organized teams a step further but allowing them to choose what to work on as well. This creates a team that not only organizes itself but also manages itself.

It also specifically changes the term ‘Development Team’ with simply ‘Developers’ to help eliminate this ‘team within a team’ phenomenon.

Another big note in the area of teams involves the Scrum Master.

While the 2017 Scrum Guide never mentioned accountability for the Scrum Master, the 2020 guide mentions it twice:

  • The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide
  • The Scrum Master is accountable for the Scrum Team’s effectiveness.

The message is clear here – the Scrum Master is in service to the organization as a whole and they must manage both up and down as ‘true leaders who serve’ rather than ‘servant leaders’ in their role.

In action, a self-managing team should be able to autocorrect itself and make constant improvements to what they work on, how they do it, and who is involved.

Introducing a new Sprint Planning topic

Sprint Planning has always included the “What” and “How” topics to determine the work that will be done within the Sprint.

In the 2020 update, emphasis is placed on a third topic, “Why,” which refers back to the Sprint Goal and reminds the team that they should always be asking themselves how the current Sprint will create progress on their overall Product Goal.

Along with the idea of self-managed teams, the new Sprint Planning topic reinforces the concept of doing the ‘right’ work.

Allowing Scrum to reach a wider audience

The 2017 Scrum Guide still contained many references to the IT-related fields that were crucial to the creation of Scrum, as well as a few redundant or complex statements that made the framework less approachable for some businesses.

With the 2020 update, the Scrum Guide has removed the redundant language and simplified the message of the Scrum framework so that it is easier to understand and implement within a wider audience. In fact, it’s about 30% shorter than the previous version and provides clearer and more actionable information for readers.

By changing up the tone and context of the Scrum framework, more and different businesses will be able to take advantage of a methodology that has proven to get twice the work done in half the time.

How is Sigao Studios handling these changes?

At Sigao, we’ve trained hundreds of students over the years on how to practice “good Scrum” and avoid “bad Scrum” using the principles and framework included within the Scrum Guide. We’ve also consulted with and worked alongside dozens of companies that depend on us to improve their business through Agile transformation and Scrum implementation.

With the 2020 Scrum Guide update, nothing changes – we will always provide the most up-to-date and relevant information for all of our clients and students.

Remember that Scrum is all about pivoting to adapt to the changing landscape, and these updates are just that – a pivot.

We look forward to bringing these changes into the real world so that we can test their effectiveness, continue to improve, and show everyone the value of Scrum.

Student Spotlight: Carmen Mays of Elevators!

We recently caught up with Carmen Mays, Founder and CEO of Elevators, to ask her about the impact that her recent Scrum Master and Product Owner training has made in her professional life.

First, a little about her company:

“Elevators fosters equitable entrepreneurial ecosystems by developing innovative corporate supply chain strategies. We build community and capacity for melanated creatives and institutions integral to the entrepreneurial ecosystem.

I started Elevators with the simple premise of ensuring creatives of color had the tools and opportunities they needed to make a living doing what they love. Elevators has successfully engaged creatives in culturally relevant business development. Elevators also creates corporate engagement and supply chain strategies that foster equitable entrepreneurial ecosystems.”

You can find out more about her company, Elevators, right here.

Since this was a short interview format, I’ll just list the questions along with her responses below!

Q: How has the Scrum Master and Product Owner training changed the mindset with which you approach your business?

I am much more clear about how to introduce new ideas and refine existing ones. I am able to go deeper into the structure of the products thereby making them more effective.

Q: Have you incorporated any of the training into your workflow yet?

Yes! Particularly the Kanban Board.

Q: Have you seen any immediate benefits to bringing these thought processes into your business?

I’m much more productive and because I can see what I’ve completed, I don’t overwork.

Q: Do you think LSM/LSPO training would be helpful for other startups?


Q: Would it be an added benefit for all members of a team to have this training (so that everyone understands it and are on the same page)?

Yes! As with any training, it’s for everybody.

If you are interested in learning more about our LSM (Scrum Master) and LSPO (Product Owner) training classes then head over to our class page to get the details. Currently, those living near Birmingham, AL might even be eligible for a full scholarship to attend!

Student Spotlight: Maureen Sears of HC3!

We recently caught up with Maureen Sears, Project Manager at HC3, to ask her about the impact that her recent Scrum Master and Product Owner training has made in her professional life.

HC3 is a data-driven tech company delivering customer communications for their clients. By managing complex data generated from multiple client systems, they help financial service organizations communicate with their customers in meaningful ways. HC3 offers focused solutions for statement and notice redesign, intelligent marketing campaigns, and seamless delivery of both print and digital communications. Through these solutions, HC3 empowers financial service organizations to give their customers a fully customizable document experience.

You can find out more about her company, HC3, right here.

Since this was a short interview format, I’ll just list the questions along with her responses below!

Q: How has the Scrum Master and Product Owner training changed the mindset with which you approach your business?

As a team, our Project Management team has adopted a more fluid perspective on how we handle implementations. Our improved mindset allows us to more easily adapt and grow with challenges that come our way.

Q: Have you incorporated any of the training into your workflow yet?

One of the most important pieces of training that we have incorporated into our workflow is the feedback loop.

Constantly sharing ideas between other departments and getting feedback from our clients has enabled us to deepen our understanding of other departments to create a better experience for our clients.

Q: Have you seen any immediate benefits to bringing these thought processes into your business?

Our digital solution HC3 offers our clients is constantly evolving and improving, so the implementation process is constantly evolving and improving at the same time.

We have been able to refine the process and tool more rapidly than ever before by including a constant internal and external feedback loop.

Q: Do you think LSM/LSPO training would be helpful for other startups?

This training did a great job of building the foundation for working in the Scrum world. It would be extremely beneficial for a startup because it is easier to get everyone’s commitment to building a new process instead of changing an existing one.

Q: Would it be an added benefit for all members of a team to have this training (so that everyone understands it and are on the same page)?

We were fortunate enough to have members of our project management team, as well as the manager of the development team, participate in the training. Having everyone together to think about how we could apply this knowledge in our work environment and bounce ideas off each other during the course was invaluable.

If you are interested in learning more about our LSM (Scrum Master) and LSPO (Product Owner) training classes then head over to our class page to get the details. Currently, those living near Birmingham, AL might even be eligible for a full scholarship to attend!

Student Spotlight: Ethan Summers of Fledging!

We recently caught up with Ethan Summers, Commercial Operations Lead with Fledging, to ask him about the impact that his recent Scrum Master and Product Owner training has made in his professional life.

Fledging is part of Birmingham, AL’s rapidly growing tech startup community and they are doing some awesome things with product design and release in the portable SSD space. If you have a need for fast, secure, portable, and stylish storage, check them out here.

Since this was a short interview format, I’ll just list the questions along with his responses below!

Q: How has the Scrum Master and Product Owner training changed the mindset with which you approach your business?

We’re building into everything. We’re a startup in an industry full of tech titans with huge bank accounts, so all we really have is our creativity and agility. Scrum is helping be a lot more nimble. One major way is our Product process. We’ve rebuilt how we evaluate product concepts so that we get to “Yes” or “No” faster and in a validated way. 

Q: Have you incorporated any of the training into your workflow yet?

We’re right in the middle of that right now. The Product example above is one good example. But we’re trying to use it for everything. We don’t see any domain as off limits, even the “perpetual work” domains like our Production team, because they can run process improvement sprints or even decide to treat a whole month, with all its Production demands, as a kind of sprint. We’ve also started using concepts like the Daily Roundup right away. 

Q: Have you seen any immediate benefits to bringing these thought processes into your business?

We have! The Daily Roundup came at the perfect time during the quarantine. It would be really easy to lose touch with each other. Instead, we implemented Daily Roundups and now we all touch base at the beginning and end of each day to discuss what we’re working on, expected roadblocks, and so on. Our team’s reporting a lot of satisfaction both personally and professionally with this process.

Q: Do you think LSM/LSPO training would be helpful for other startups?

As long as they’re not a competitor, absolutely! But it would be a terrible waste of time for our competitors. 

Q: Would it be an added benefit for all members of a team to have this training (so that everyone understands it and are on the same page)?

Yes, I think so. Our CEO already has the training. Our CSO and I went through the same class. We have a Software Engineer going through it right now and our Head of Operations goes in May. Frankly, I think everyone on our team should do it. 

If you are interested in learning more about our LSM (Scrum Master) and LSPO (Product Owner) training classes then head over to our class page to get the details. Currently, those living near Birmingham, AL might even be eligible for a full scholarship to attend!

Environment settings in an Angular CI/CD build process

The Problem

When building large-scale Angular applications, most people eventually need to provide their application with environment-specific variables, which doesn’t seem like a very big deal on the surface.  After all, Angular provides us with the “environment.ts” file, right?

It should be as easy as filling in your environment settings and then using the environment variable throughout the site, but this method introduces a level of uncertainty into the build process that may not be acceptable for all applications.

This uncertainty comes primarily from the need to rebuild the application before those new variables are accessible.  For example, when changing from a Dev environment to a Test environment, the build process is at the mercy of hundreds of code packages that may or may not have updated since the last environment promotion.  This can cause time-consuming build errors that aren’t even related to the quality of your code.

In some instances, it may be possible to avoid these errors by locking down dependencies with something like “npm shrinkwrap.” However, due to the complexity of the Angular CLI build process, this approach still allows for the potential of different outputs. Even if you manage to get consistent outputs, it’s still time-consuming to constantly rebuild the application in a build pipeline that could potentially get backed up from rapid promotions.

The Solution

Before the application loads, retrieve a CI/CD generated settings file from the server, which allows you to make sure that an unchanged code base can get up to date settings no matter the environment. Here’s how our process works:

Create the configuration service

First, we create a service in one of your top-level Angular modules, typically the App Module or, if applicable, the Core Module.  You can also create this service in any non-lazy loaded module that provides services to the application.

    providedIn: 'root',
export class AppConfigService {

    public settings: AppSettings;
    get WebUrl() {
        return location.protocol + '//' + + '/';
    constructor() {}
    public load() {
        return new Promise((resolve, reject) => {
            const self = this;
            const xhttp = new XMLHttpRequest();
            xhttp.onreadystatechange = function () {
                if (this.readyState === 4 && this.status === 200) {
                    const data = JSON.parse(this.responseText);
                    const jsonConvert = new JsonConvert();
                    self.settings =  jsonConvert.deserializeObject(data.BaseSettings, AppSettings);
                if (this.status === 404) {
                    reject('Server cannot find Appsettings.js file');
  'GET', 'appSettings.json', true);
        }).catch(error => {

The “load” function is where we get our settings.  Unfortunately, we can’t use Angular’s built in HttpClient because it forms a circular reference with our authentication service, but depending on your project structure, you may be able to simplify this request with built-in Http functionality.

After we receive the data, we use an external library (Json2Typescript) to convert the settings JSON into a typescript class so we can include helper functions if necessary. We then assign this object to the “settings” property on this service to be used elsewhere.

Create the appSettings.json file

This file structure is entirely up to you and your preferred CI/CD tool, but here’s an example for reference.

  "BaseSettings": {
    "ApiUrl": "http://localhost:99999/api/"

Include the appSettings.json file as an asset

Angular needs to be informed specifically about which files are assets so it includes them in the build process. We place our appSettings.json in the root “src” folder of our web application. Because of this, our assets list inside of the angular.json file looks like this:


If you place the settings in a different folder, you’ll need to link directly the file, rather than the folder location (e.g., “src/assets/appSettings.json” rather than “src/assets/”).

Tell the app to load settings before launch

The last step on the client side is to make sure the application knows to load the settings before anything else initializes. This is done through Angular’s built-in APP_INITIALIZER function. Below is an example of our core module using the APP_INITIALIZER to load settings.

export function loadConfig(config: AppConfigService) {
  return () => config.load();

  imports: [
  declarations: [MainNavComponent],
  providers: [
      provide: APP_INITIALIZER,
      useFactory: loadConfig,
      deps: [AppConfigService],
      multi: true
export class CoreModule { }

Your factory function should return a function that returns a promise. As you can see, we’ve injected our App Config service and returned our “load” function, which will return a promise. Once that is completed the rest of the application will be allowed to load, and the configuration service, with settings, will be available throughout the application.

Configure the build service

At this point, your angular application should be set. The only thing left to do is configure the release service to change the appSettings.json for every environment, and your application should retrieve them properly when it starts. We use Azure DevOps build/release to update the appSettings.json file, but you can use any release-management tool that supports updating json files.