Sigao in Birmingham: Why Our Move Mattered

Regions field in Birmingham

In 2017, as founders of a newly formed company, we made the strategic decision to move to Birmingham, AL. There are quite a few reasons why Sigao moved to Birmingham, but one primary reason stood out above the rest. A seed planted in the wrong soil isn’t going to grow, no matter how well you take care of it. For Sigao to grow, we needed a place where the community’s culture fit with the culture we wanted to build. In this blog post, we’ll take a look at the reasons behind the move, how the city has positively affected the company, and what the future holds for Sigao in Birmingham.

We moved for the startup scene

When Sigao made the move to Birmingham we weren’t much of a company. Just four people in basement with a few minor contracts to keep us going. In fact, on paper it probably wasn’t even the right move. When we changed locations we increased our cost of living, increased our competition, and severed many of the connections we had in our previous city. However, we knew that something was happening in the Birmingham tech scene, and we knew we wanted to be a part of it.

What we found surprised us.

We quickly discovered a small yet passionate (and perhaps a bit disjointed) tech community. One that instantly opened its arms to outsiders. From the moment we arrived, we received support and encouragement from everyone we met. People we hardly knew would go out of their way to make high value introductions. It seemed their reasoning was simple: we’re a Birmingham business. That’s just what you do.

Another thing that stood out to us was the lack of harsh competition. Sigao never experienced the cutthroat, calculating environment that so many startups deal with. Instead, we saw companies passing work opportunities to other members of the community. We met business leaders promoting partnerships and collaboration over cold business strategy. Most importantly, we met a group of people stubborn enough to look at huge problems and think “I can fix that”.

We moved for the food

We have always believed that part of being successful at work is being happy outside of work. And to us, few things contribute to happiness and wellbeing like good cuisine.

Food provides a lot of things that other forms of entertainment do not. Its an opportunity to connect to people around you. A chance to expand your tastes. Its even a starting point for learning about new cultures and customs that you otherwise would not have experienced. Eating is a universal activity that brings people together and broadens their horizons.

In Birmingham, we found a vibrant food scene that still continues to surprise us years later. Fine restaurants serving dishes that rival those in major cities. Breweries with food so good they win awards. Hole in the wall shops serving the same meals for over 100 years. The city may be small, but it plays in the big leagues. Even in a post-COVID era, with our team’s rarely ending up in one place, we still make it a tradition to order the same local meals every time we’re together.
Employee wellbeing and happiness is a top priority for Sigao, and being in an area with a rich food culture has helped fulfill that mission. It may seem like a minor thing, but good food is the focal point for many things that aid wellbeing. Its allowed us to explore the city, support local businesses, meet new people, and form bonds with each other and the community.

We moved for the people

Before making the call to move, we had only a basic understanding of Birmingham’s culture. We knew about its history (both recent and distant), and knew that people were working hard to push the city’s image into the future. But, beyond that, we really didn’t didn’t have a strong understanding of the community we were about to join.

Still, we were drawn to the city’s spirit of change and forward-thinking attitude.

It didn’t take long for us to realize how deep that attitude runs. The city is practically overflowing with individuals and groups working to make the city better. From dedicated economic centers, to environmental organizationsLGBTQ community groups, and revitalization advocacies, the city has a culture of progress and civic engagement that we’ve never experienced anywhere else.

Having access to a community like that is not a trivial thing. Starting a business is a difficult, lonely endeavor with a high failure rate. Often the biggest challenge is simply maintaining optimism in the face of hopelessness. It makes a huge difference to know that the people around you truly believe in the future of your city.

In a way, the city its self is a startup, which is why it fits us so well.

Its a group of people using imperfect tools to achieve a common goal in the face of long odds and deep setbacks. It doesn’t matter if you’re talking to a tech entrepreneur, a lawyer, a bartender, etc. People here have a shared connection and sense of purpose when discussing what the city could be. Its been inspiring and energizing to be a part of that, and we attribute a lot of our success to the people fighting to make the city better.

Environment matters

If there’s one thing we’ve learned on this journey, its that your environment is important. No matter how talented you are, and no matter how hard you work, you’ll always need support and collaboration from the people around you.
As Sigao enters its 7th year in business, we’re transitioning to a stage where we can be on the other side of that support. I recently witnessed someone refer to Sigao as an “established” Birmingham tech company, and I’ll admit it kind of floored me. Its difficult to think of yourself as “established” when the memories of working out of a cramped living room are still fresh on your mind.
Yet, after some reflection, I realized they were right. At some point in the last few years we stopped being the newcomers searching for a place to plant our flag, and became part of the community that drew us here.
That means we now have an obligation to those that come after us. Whatever the future holds for Sigao, one thing is clear. We’ll be here, along side the rest of the community, offering support and encouragement to anyone else who decides to join us. That’s just what you do.

Do I need custom software?

Man confused by plans for a custom software system

As veterans of the custom software industry, our team has encountered countless questions about the creation of custom software solutions. However, few questions are as difficult to answer as the very first one.

“Do I need custom software?”

Software is wildly complex, both from an engineering perspective, as well as a business value perspective. Today’s applications can touch so many aspects of an organization that accurately gauging the investment can be a challenge. On top of that, no two engineering firms are the same. Some may provide ultra-specialized engineering services for one aspect of the project, while others may provide broader, more consultative services that cover more of the project scope.

The natural reaction to attempting to process too many choices is to intuit the answer. To try to “feel” that the variables are pointing one direction or another. This is dangerous as it leads to Confirmation Bias, giving you the impression that all the information you discover appears to point in the direction you want it to point.

In this article, we’ll discuss some tangible aspects to consider that will provide a framework for making the decision. Keep in mind, this is too complex of a subject to cover in one article. Our hope is that this information provides valuable measures that help you feel more confident about the process.

Analyze the “Why” Behind Your Custom Software

Every software project begins with the same thing: a problem.

Unfortunately, people are good at solving problems.

Take a minute to think through the last problem you solved. It can be anything. Maybe your phone wasn’t working, or your car was making a weird noise. Whatever it was, think about how you instinctually responded when you discovered the issue. I’m willing to bet that the first thing you did was immediately start trying to figure out the underlying cause.

Did you mull it over in your head, vetoing unlikely scenarios and coming up with new explanations. Maybe you googled the issues, trying to find others who have solved this problem. Whatever path you took, its very likely that you got sucked into finding a solution without paying much attention to the problem its self.

People are hardwired to solve problems. We’re good at it, and by and large, we enjoy it. Unfortunately, that aptitude leads us to dive into solutions, while giving the problem only a cursory glance. Maybe the cost to fix the problem isn’t worth it? Maybe the problem opens up doors to fix other areas? What if there’s an ugly, but effective solution that’s far easier than the obvious solutions?

For small, every day problems, the downside of ignoring this kind of deep analysis is minor. A few hours here, a few dollars there, no big deal. Yet, software projects are huge investments, with vast consequences. Most problems are solvable, but the real question is should you solve them?

Know your problem, ignore the solution

Nothing related to a solution matters at this point. Not the price of the solution, not the technology (or lack there of) of the solution, only the problem. Our team consistently encounters people who “know” what software frameworks we need to use to solve the problem. Yet these people often are not able to describe the problem in detail. They’ve allowed themselves to dive into the solution without truly knowing the value of the problem, which makes the decision little more than a gamble. Before moving forward, these are some of questions you should be exploring:

  • How many people does this problem effect?
  • How much time/money do you lose from these effects?
  • Are there 2nd or 3rd parties affected by the primary party’s issues? How much time/money do you lose there as well?
  • Are there multiple facets to this problem? If so, which is the most valuable to solve?
  • Are there adjacent issues that you can address in tandem with the primary issues?

The more you can understand the problem, the more you can assist other’s to build a good solution.

Why knowing your problem is so critical

The less you know about the value of the problem, the more you end up guessing about the value of the solution.

At its core, a software project is a continuous cost/benefit problem. You expend X amount of effort for Y amount of return. If done correctly, Y ends up significantly larger than X. Because of this, one of the largest factors in a successful project is how well those involved understand the problem.

The less you know about the value of the problem, the more you end up guessing about the value of the solution. Each decision becomes a gamble, rather than a calculated risk. And you will be making decisions if you continue down this path. As the owner of a project you will face a constant stream of decisions related to the value of your solutions.

Do you sign off on using a 3rd party tool that costs $100/month, but will end up saving 2 months of project work? What if that feature is only solving a problem that costs a handful employees 10 minutes per day? Engineering groups can provide information, and some (Sigao being one of them) can even assist in analyzing those choices. But, the final decision must come from those who understand the problem the best.

The next reason is perhaps the most important. It’s what elevates project outcomes to to their maximum potential:

Extreme understanding of the value of the problem allows for the most creative solutions.

Knowing your problem fosters innovation

Knowing what is and isn’t important allows the engineering team to propose creative solutions. My favorite example of this is what happens in some of our initial discovery meetings. People will often approach us to build a project having already landed on a desired solution. They’ve spent weeks or months imagining a complex solution that addresses ALL their problems, without knowing the value of those problems individually.

This is a common scenario, which we address with an array of discovery questions. We try our best to help our customers refined down the most valuable aspects of their solution. During that process we occasionally encounter situations where the value is so concentrated on one aspect of the problem, it allows us to bypass the majority of their requirements. If only a handful of requirements are worth the investment, why bother with the others?

The results are often eye opening. Given a narrowed scope, the team is free to adopt a more Rapid Testing mindset. We’re able to suggest ideas that may not even involve writing code, but will solve the problem quickly. This allows the customer to assess portions of the solution individually before committing to a large scale system. Sure, these solutions are typically “quick and dirty”, but the amount of value they provide negates the downsides.

Its not uncommon for our customers begin a meeting envisioning a $50k+ system , only to leave the meeting with a way to solve most of their problems for free. All because they were able to recognize the most valuable problems to solve.

That’s the power of understanding your problem. When you know what’s most valuable, you gain the ability to make more intelligent decisions about where you invest your time and money.

Long Term “Why” Behind Your Custom System

One of the biggest issues we struggle with in the software industry is conveying the benefits of a custom solution. It’s difficult for people to get past the initial shock of the price, and a lot of that is because they haven’t truly considered the problem their solving.

Custom software systems are like sports cars. Expensive to build, expensive to maintain, but capable of doing amazing things. Part of knowing your problem is knowing how much the value of the solution builds up over time. If you a development team quotes you $300k for the solution, is that bad? Maybe. What if it will save you $70k per year and will turn a profit in 3 years? What if you’re currently paying $40k/year in subscription costs which will disappear after the project?

Think back to the “adjacent issues” you explored. Could owning your own data provide more opportunities for value over time? Could you later pivot your solution into a product that you then sell to other companies similar to your own?

Time is a powerful factor when considering the problems you’re solving. Solutions typically provide value for long after the initial project cost.

How Much to Invest in Custom Software

By now, lets assume you have your problem mapped out. You know how many people it affects, how much they lose, and how much money you’re losing by not addressing the issue. The next question is, can you feasibly afford the solution?

Custom software is expensive, and there’s not much you can do about it. Even if you are absolutely convinced of the value of your project, there will still be significant investment to get to the end goal. There’s no cutting corners if you expect good project outcomes, which is why its so important to know what you stand to gain. We plan to cover this topic in more detail in later articles, but for now we’ve provided a reference table for you to plan against.

Keep in mind, many factors affect these prices. Some seemingly difficult features are solvable in days, while others that appear simple can take weeks or month to accomplish.

Reference Table For Estimating Project Costs

Project Type
Price Range
Simple Marketing Website (Contractor)
A simple marketing website meant to display information, built by an independent contractor. Primarily needs to look good, function on mobile. Functionality would be limited to simple contact forms.
Simple Marketing Website (marketing firm)
A simple marketing website meant to display information, built by an experienced marketing firm. Primarily needs to look good, function on mobile. Functionality would be limited to simple contact forms. Typically would include more robust designs/mockups, more help with hosting, as well as maintenance and trouble shooting.
Proof of Concept Web/Mobile App
Web or mobile app, built by an engineering firm, designed to show that the intended functionality is possible. May not be complete, or visually appealing. May not scalable. These are typically used to attract investors.
Mid size Web App
Web or mobile app, built by an engineering firm, designed to accomplish a business function. These may absorb several business areas, allowing the company to remove multiple paid products from their workflow. This price range may also be applicable beta product launches, depending on the complexity of the product.
Enterprise Web App
These are large, overarching systems that touch multiple aspects of a business and hundreds of users. These systems have multiple integrations with other systems, multiple roles throughout the organization, and strict uptime requirements. For new products, this range would likely cover several major versions of an early stage product. If promoted properly, a new product with this much investment should typically be generating revenue and attracting large investment firms.

Follow Through with your Custom Software Project

You know your problem, and you have an idea of what its going to cost. Now what?

If you have the corporate backing or funding to move forward, the next step is to start evaluating vendors. Spend time finding a group that’s trustworthy and has a proven track record. Make sure their clients willing to vouch for their capabilities. Find out if they hide the development team, or let you interactwith the people building your solution. Finally, make sure their contracts are set up to share risk on both sides of the project, rather than pinning it all on you.

Most of all, find someone you get along with. There WILL be stress, there WILL be miscommunication. The best way to navigate that is by working with someone you trust.

Final Thoughts

Assessing whether you need custom software is a difficult task, but it doesn’t have to be guesswork. Sure, you won’t always find perfect ways to assign value to the problems you’re trying to solve. You won’t always have all the information you need to make a perfect decision. However, with a little effort, even the most complex problems can be evaluated and broken down in a way that empowers you to make better decisions.

Have fun solving big problems!

Rapid Testing Mindset: A Powerful Strategy

Perfect Doesn’t Mean Effective

Rapid testing is not something that comes naturally to me. As an engineer and a creator, I often find myself driven by the pursuit of perfection. In my spare time I spend days and weeks on woodworking or home improvement projects as I hone my skills and improve the quality of my work. In fact, I’d guess that just about everyone has a skill or interest they want to learn and work hard to improve upon. Likewise, I’d guess that most people view the pursuit of greater skill and higher quality output as the path to success. For the most part I would agree with them.

It may then surprise you that one of the most powerful strategies in business is to NOT pursue perfection.

Examples of this strategy are evident everywhere in the business world. New services often launch with messy, unintuitive signup processes. B2B applications rarely end up with clean, visually appealing interfaces. More and more products are releasing in “generations” rather than perfectly finished designs. In fact, while writing this article I prepared ramen with instructions to “ignore the indicated fill line” rather than the manufacturer simply providing a bowl with a correct fill line.

These trends are all coming from large companies with resources and talent capable of making their work “perfect”, so why are so few of them pursuing it?

80% of Consequences Come From 20% of Causes

To understand why, we first need to understand the Pareto Principle, also known as the 80/20. First proposed by management consultant Joseph M. Juran, the 80/20 Rule states: for many outcomes, roughly 80% of consequences come from 20% of the causes. While originally used in the context of quality control, the principle has been successfully observed in many practices. In fundraising, 80% of the funds raised typically come from 20% of the donors. In computing, developers can typically fix 80% of software issues by addressing the top 20% of bugs.

What people often overlook is how this holds true for business activities as well. You will likely capture the majority of an activity’s value at the beginning, with returns on investment diminishing as the effort continues. Although the perfect solution may in fact be achievable – and even more valuable – this principle shows us that the point when expended effort becomes a net loss is far earlier than “perfection”. Within that final 20% of quality lies the vast majority of our time and energy, which would be better served accomplishing 80% of several other business outcomes.
In short, perfection wastes time and money.

Speed is the Optimal Path to Success

The chart below represents an 80/20 curve relating to the business value of tasks. Each bar represents a task and its measured business value. What the 80/20 Rule shows us here is how 80% effort is “optimal” in relation to the value we get out of our actions.
Diagram showing the diminishing returns that rapid testing lets you avoid.
However, with concepts as abstract as “effort”, shooting for a real number is futile. We can’t accurately quantify our effort, and even if we could, landing directly on 80% would be virtually impossible. How do you put in exactly 80% effort when doing things like deciding on sub-contractors or creating sales collateral?
If more value exists at the beginning of our efforts than at the end, it stands to reason that taking too long is more costly than finishing too early. Thus, our goal should be to focus on speed.
By focusing on speed, we ensure that if we miss the 80% mark we still “fail” in the most efficient manner. To see this in action, imagine two identical startups selling their own widgets. As these businesses grow, both startups realize they need some sort of CRM to manage customers and orders. Startup A, recognizing that this is a core part of their business, launches a two-week research project to determine the absolute best fit for their company. Startup B, however, spends an afternoon researching options then picks one that seems decent.
Fast forward two weeks… Startup B realized they rushed their decision and some business processes will have to remain manual. However, they now have two weeks of customer data in the system and are using this data to create sales strategies. Startup A ended up with the “perfect” solution with all tasks perfectly automated, but no data to determine sales strategy. They are now two weeks behind their competitor. Only now are they starting to enter customer data, and it will be another two weeks before they have enough information to start developing a sales strategy.
Startup B captured the bulk of the business value (a way to build a sales strategy) despite rushing the research task and failing to address some lower value business processes with their purchased software, whereas Startup A missed out on leveraging high value results because it was stuck waiting on “perfection”.

The Difference Between Rapid Testing and Recklessness is How Much You Learn

At this point you may think I’m encouraging you to act recklessly. I know I certainly thought that the first time I saw these rapid testing concepts in action. There is a final aspect separating recklessness from strategic speed: learning. Or, more accurately: you should frame your pursuit of the 80% value in the context of learning new information to apply to your next decision or action. When you treat every next move as a deliberate test for gathering information, you gain the insight to deploy your effort where it matters the most.
Let’s go back to our startups. This time Startup B had massive problems with the software that they selected. A purely speed based strategy would tell them to pick the next best software and cross their fingers it would work better. Technically they would still accomplish more because of their speed, but they also would still be charging down the same path without knowing if it was the right path. What happens if they treat the decision as a test with the explicit purpose of learning about their sales needs?
By framing it as a learning-based strategy, Startup B would pay closer attention to the business value provided by the software and note what conditions would cause them to change directions. These insights could lead to a better next pick but, more importantly, this deliberate focus on learning may reveal that the company’s business process doesn’t actually need a CRM at all.
Maybe these widgets require a unique sales process, or maybe a CRM is too complex and unwieldy to use efficiently at this stage. If that’s the case, their next action would be to pivot quickly to some other solution, completely abandoning the goal of getting a new CRM and saving money in the process. By inspecting the results, Startup B will gain business value even in failure.
Speed helps you get to your goal. Testing helps you determine if your goal is correct.

Rapid Testing Mindset is a Powerful Strategy for Innovation

Regardless of job title, everyone is operating with an incomplete understanding of their environment. Whether we know it or not, we conduct experiments every day with every action we take. Despite this – maybe even in spite of this – many companies punish failure and expect every result to be positive, leading employees to push deeper into the low value, time-wasting activities as they attempt to be “absolutely sure” their results will be positive.  Some byproducts of this risk aversion are lower creativity and lower trust between employees.

However, companies that embrace rapid testing, and the failures that come with it, create an environment suitable for innovation. When the organization’s goal becomes learning, failures no longer carry negative weight. Instead, failures are celebrated as steppingstones towards better results. This environment is critical for innovation because, by definition, innovation is the exploration of the unknown. Exploration cannot exist without risk and creativity. If perfection is expected and failure is not an option, the business will get mired by group think.

Even failure-embracing organizations can stifle innovation if they remain focused on perfection. Innovation is a time-consuming process, often taking hundreds of iterations to find the best solution. When perfection is expected before results are known, these types of organizations will spend the majority of their time on the low value items that make up the last 20% of quality.
If the 80/20 Rule holds true, every “perfectly” completed task sacrifices the same effort as five 80% completed tasks. That’s four missed learning opportunities for every attempt. The result is large feed feedback loops, low agility, and even abandoned projects as the effort to gather new information becomes too costly.
Organizations embracing rapid testing will experience failure. It will be messy and often chaotic. However, these organizations will also generate business insights far more quickly than their competitors. They’ll be more agile, more responsive to changes, and, by necessity, foster cultures of exploration and creativity.

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

Does Agile Scrum Kill Innovation? (Iterative Problem Solving)

Scrum is designed to solve interrelated problems common – but not unique – to software development projects: project scope and estimation.  

Do these problems also exist in innovation projects? Will the Scrum solutions work for innovation projects as well? Short answers: Yes and Yes. 

Applying Agile Scrum methodology to the process of Innovation allows the product team to define the scope of the project more clearly, identify emergent work more easily, estimate the work to be done more accurately, and demonstrate value to customers and stakeholders more frequently.

Let’s walk through what Scrum looks like within traditional software development and then pair it with common problems faced by innovative teams.

How Scrum uses emergent prioritized work to solve problems

Scrum developed ways to address the problem of project scope (the total amount of work needed before the project can be considered done). Since software can do so many things, it is hard to limit our needs. Therefore, project scope in software development has always been a huge problem.  

In software development projects, project scope usually starts out too big and only increases as the project progresses. Without understanding the project scope, it is hard to know when a software development project is ‘done.’ Therefore, projects often end when they run out of money or time, rather than being declared ‘done.’

Scrum addresses the project scope problem through ’emergent prioritized work,’ collectively referred to as the backlog. The backlog starts with currently known work and collects emergent work as the effort proceeds.

In Scrum, one person (the product owner) prioritizes the backlog; this makes the backlog manageable. In each iteration, the team faces a limited set of high-priority work and understands what it means to declare that set of work ‘done.’

When an iteration is completed, the project must always be functional so the users can touch and feel it for flaws or errors. Each time, the product owner shows the results to the users and asks their opinion on business value created or development errors (often some version of ‘what do you hate most’). In this way, the biggest possible mistake or waste of time is limited to a single iteration. If the project is off the rails, it can be reoriented before too much damage is caused. Thus, the process creates ideas for additional, emergent work which can be added to the backlog. 

The product owner prioritizes the backlog items according to business value. In this way, the product owner can compare the business value created by an iteration to the cost of that iteration. If there is no combination of work items with a total business value larger than the cost of an iteration, then the project is finished. 

Innovation projects have similar problems.

How do we decide what the most pressing problem is?

How can we know when we’re done (or even when we will be done)? 

Why Agile Scrum is best for innovation 

We build the result a little bit at a time, ensuring the work we’re doing fits within the whole idea of done and to make sure we’re also collecting any emergent work. This incremental approach helps solve scope problems in innovation projects, just like it does in software development projects.  

Another problem iteration can help solve is estimation. Everyone wants to know how much a solution will cost and/or when it will be done.  

Any time we discuss something in the future, we engage in estimation. Given what we understand in the present, we make predictions on how the future will play out. Unfortunately, the only truth we can predict is that humans are terrible predictors of the future (flying cars, anyone?).

In fact, we are so terrible at prediction that our only defense is to think small. Scrum helps solve this by using an iteration small enough that it allows:

  1. Product backlog items to be estimated reasonably well
  2. The risk of an estimation error to stay at a manageable size. 

Over a handful of iterations, the team’s productivity per iteration (velocity) becomes apparent. The product owner can then estimate the completion of the known backlog with a reasonable level of accuracy. If this estimate is over budget or schedule, the backlog can be pruned, and/or the organization can (carefully!) work to increase the team’s velocity. 

When you’re involved in innovation efforts, consider a lightweight Scrum process involving:

  1. A backlog of needs
  2. Iterations of work focused on a few specific needs from the backlog
  3. Regularly showing how your solution actually works (even if it works poorly).

This way, you can focus on the most valuable work while effectively collecting emergent work and managing costs and schedules.

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.