Skip to main content

What can cause product instability?

There are different factors that can cause a Scrum Team to introduce instabilities into their product Increments:

  • Quality regressions produced by uncaught errors. Sometimes, when a Scrum Team adds a new capability to the Increment, they inadvertently break something that worked before they added the new capability. This occurs quite frequently in software products, but it can also occur on physical products, such as when something like the product exterior is redesigned and makes certain buttons harder to access. Or, another example is when a team changes the touch-sensitive display to make it more impact resistant but that also makes it less responsive.

    A test first approach can help a Scrum Team to reduce or prevent quality regressions and uncaught errors. When the tests produced by such an approach are automated and executed using Continuous Delivery practices, they provide developers with immediate feedback they can use to eliminate quality regressions.

    Improving code coverage, which measures the extent of the code that is exercised by tests, can also help to catch uncaught errors.

  • Architectural degradation caused by exceeding design limits. Products are a lot like buildings - sometimes changes that seem simple can cause the product to fail in spectacular ways. Consider the roof of a building that is designed for a particular load, and even a little more. Up to that design limit, load can be added to the roof, but at some point even just a little more load will cause the roof to fail. This could happen when an air conditioning unit is upgraded to handle hotter days and heavier cooling demands.

    The concept of a Minimum Viable Architecture (MVA) can help Scrum Teams to ensure that each product Increment has just enough architecture to be able to preserve the value that it has provided in the past while exploring new opportunities to improve the value that customers experience from the product. The idea behind the MVA concept is that each product Increment must consider not only functional capabilities of the product, but also how the product’s architecture must evolve to continue to meet the quality goals for the product.

  • Accumulated Technical Debt. Technical debt can be thought of as something that a team accrues, borrowing against their future productivity by taking short-cuts in creating product increments that may need to be fixed at some later time. Technical debt is not un-done work, as it meets the Scrum Team’s Definition of Done.

    Incurring technical debt, instead, involves making expedient short-term decisions that aren’t sustainable in the long run. An example of this is producing a product Increment that supports the early adopters of a product but may not support large numbers of users at a later time. At the time the product Increment is delivered, scaling is not a problem, but if the product is successful and gains customers, at some point portions of the product may have to be redesigned to support greater numbers of users.

    One strategy for reducing technical debt is to track design trade-off decisions that increase technical debt, and to reserve a portion of the Scrum Team’s capacity every Sprint to work on finding better solutions to these “shortcuts” that the Scrum Team has taken before. However, if trade-off decisions are frequently put off to the future, or technical debt continues to grow over time, the Scrum Team may not be effectively managing their technical debt and they may be compromising the long-term viability of the product.

  • Failing to apply fixes to all variants of a product. When a Scrum Team maintains more than one version of a product, they must ensure that when they fix defects in one version of the product, they also fix the same defect in all other versions of the product or they risk having some product versions degrade in quality.

    Some techniques for reducing the cost of this include:

    • Use feature toggles. Only having one version of a product, but controlling alternate product behavior with feature toggles that turn capabilities on or off when the product is used, eliminates the need to maintain different versions of the product.
    • Use common components or a shared platform. When changes are limited to common components or a shared platform, they only need to be made in one place. The Scrum Team will still need to test all product variants, but not having to make the same change in different places reduces the chances for human error caused by inconsistent updates.

 


Resources:

Blog Post
“What is a good speed to drive?”. The answer depends on a lot of things like: where do you drive (in a residential area, on a highway), are there speed limits, what are the weather conditions, etc. But more importantly, since when is driving at a particular speed a goal? Getting to a certain locatio...
4.6 from 37 ratings

 

Blog Post
As the name “Test First” suggests, you write a test first before the actual code and keep them running all the time. Well, maybe not the second part explicitly. Yet what if I said to you that it actually means more than that?
0 from 0 ratings

 

Module
IntroductionThe primary purpose of Continuous Delivery is to enable organizations to deliver any type of changes such as new features, configuration changes, bug fixes and experiments into production or in the hands of the users in a safe, rapid and sustainable way through the automation and streaml...
3.2 from 3 ratings

 

Module
The “Definition of Done” (DoD) describes the quality standards for the Increment to be considered “done” and in a state that it can be effectively inspected. It provides to the Scrum Team and organization a common understanding of the completeness of the Increment. Without this crystal clarity, it’s...
4.8 from 38 ratings

 


 


What did you think about this content?


Included In

Learning Series
Scrum Teams deliver value to customers in product Increments. Product stability is vital as each Increment builds on the last.