The move toward a more agile software delivery model requires the adoption of improved technical practices. One of the first is generally the concept, and tooling associated with, continuous integration (CI). The adoption of CI practices yields other challenges, one of which is partially complete features. Many features take much longer to complete than a best practice integration cycle.
Feature toggles are a very useful way to solve this problem. By employing this concept you can effectively decouple commits and code integration from the release of a feature in that code. This is very powerful. We can now get the benefits of continuous integration without the obvious issue of exposing a partially completed feature.
Like with all things we can take this concept too far. Martin Fowler advocates for avoiding feature toggles to hide things in production:
Not everyone may be able to accomplish this easily though. It's a worthy goal to improve to over time. However, teams need to monitor for over reliance on these toggles. So a couple things to watch out for:
In a waterfall project there is a clear beginning and end, often to a fault. That's one of the things that agile overcomes very successfully. Aligning teams around a product and driving features through that team eliminates the on / off nature of waterfall projects - the eminent big bang.
With frequent releases (no big bang) it's easy to lose sight of the customer value that's hiding in your toggles. When it's time to actually release those features you could end up with a big (detoggling) bang that dwarfs its waterfall alternative. There will be other loss too aside from the customer value opportunity loss. If you encounter any issues, or as you get feedback from customers you'll need to change and adapt. Many of those features were developed a long time ago and you have all the cost of context switching and refamiliarization.
If you're going to use feature toggles to deliver your product make sure you avoid this antipattern. You'll avoid many of the heartaches that drove you to embrace agile in the first place.
Feature toggles are a very useful way to solve this problem. By employing this concept you can effectively decouple commits and code integration from the release of a feature in that code. This is very powerful. We can now get the benefits of continuous integration without the obvious issue of exposing a partially completed feature.
Like with all things we can take this concept too far. Martin Fowler advocates for avoiding feature toggles to hide things in production:
Your first choice should be to break the feature down so you can safely introduce parts of the feature into the product. The advantages of doing this are the same ones as any strategy based on small, frequent releases. You reduce the risk of things going wrong and you get valuable feedback on how users actually use the feature that will improve the enhancements you make later.He simply suggests embracing your agility. The need for these toggles means you're already releasing to production more frequently than you can complete features. Why not break the work down further, and learn from each release? Here Martin is suggesting avoiding features that will take longer than your release cycle. Instead, break them down. But a frequent production release cycle is good. Don't attempt to solve this by releasing less frequently...
Not everyone may be able to accomplish this easily though. It's a worthy goal to improve to over time. However, teams need to monitor for over reliance on these toggles. So a couple things to watch out for:
- Completed, but not released features. If you've completed a feature you should be ready to release it. Otherwise what could you have been working on instead that could be released today and have added customer value today?
- The number of hidden features. If #1 is a problem, this is likely also a problem. However, this can also manifest if you have too much work in progress (WIP). Reducing WIP can drive feature completion, therefore releasability, and therefore customer value.
In a waterfall project there is a clear beginning and end, often to a fault. That's one of the things that agile overcomes very successfully. Aligning teams around a product and driving features through that team eliminates the on / off nature of waterfall projects - the eminent big bang.
With frequent releases (no big bang) it's easy to lose sight of the customer value that's hiding in your toggles. When it's time to actually release those features you could end up with a big (detoggling) bang that dwarfs its waterfall alternative. There will be other loss too aside from the customer value opportunity loss. If you encounter any issues, or as you get feedback from customers you'll need to change and adapt. Many of those features were developed a long time ago and you have all the cost of context switching and refamiliarization.
If you're going to use feature toggles to deliver your product make sure you avoid this antipattern. You'll avoid many of the heartaches that drove you to embrace agile in the first place.
