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:
