Some teams doing incremental development can release whenever any new capability is ready. But what can you do when you need to control when capabilities are available? Consider the Backroom/Frontroom approach.
The term “Backroom/FrontRoom” comes from the Gilb’s book Competitive Engineering [see References]. It’s by analogy to a restaurant: The order the food is served doesn’t have to match the order in which it’s prepared.
For software, we can design the system to separate releasing a capability from making it available to users.
Why Not Release Continuously?
It’s great when a team can just release continuously, but not all teams can do this all the time. Consider these cases:
- Marketing: New features may need to coordinate with other people. For example, a marketing campaign may start on a certain day. Releasing early would reduce the buzz.
- Training: Some software requires that users be trained to use it well. Early release would confuse and frustrate people.
- Steady Pace: Some customers would rather that changes happen at a predictable pace, rather than when the changes are first ready. (Some product folks use a steady pace as a way to reassure stakeholders that things are progressing: making and keeping commitments builds trust.)
- Certification: Some software is regulated (by government or corporation), and accepting a release is expensive. Those teams may prefer a slow but predictable pace. For example, some health care tools must be validated with standard test data to make sure the results do not change between releases.
- Coordinate Releases: Some features work in conjunction with other features or other systems. For example, if your code can save to files but not yet load them, you might prefer to release both features at the same time.
- Perceived Fairness: Some software is developed for multiple groups, and you may want to make sure a release has at least something for each group, so they don’t feel neglected by a release.
Incremental Delivery
A big release – months of work – looks like this:
Incremental releases look more like this:
If you go in a level, the reality is messier:
The backroom/frontroom approach can give users the simpler picture, even if the reality is complicated.
Planning with Backroom/Frontroom
Staging the messy reality to work more like the simple incremental model requires care. You need to address the constraints – the reasons why you want things simpler. For example, if you’re addressing fairness issues, you’ll want to consider stories that support the various groups. You might even “save up” a few stories for each group, so you have some buffer.
Or, you may have a story that will take a long time, needing support from others. You may start a separate stream of work, often with a dumbbell shape: a pile of work at front, some low-effort time mostly waiting or coordinating, and a higher amount of work to integrate and test the result. That slow time in the middle allows you to work on other stories in parallel.
The Technical Side of Backroom/Frontroom
People have made this work using source control branches, compile-time conditional code, or simple if statements. But nowadays, many teams take a feature flag approach. (See References.) A feature flag is a special variable. The code looks at the flag to decide what to do: “If the flag is set, do it this way; else, do it that way.” There’s usually an administrative interface that controls how the flag is set, usually designed for the business side to use at will.
One way to use the flag is to reference it all over the place. That seems easy, but it is a form of duplication we’re better off avoiding. Instead, consider the Strategy pattern from Design Patterns [references]. A Strategy has separate pluggable code for the old way and the new way, and the flag can control which version is plugged in. This decision can usually be made just once.
Who Benefits?
It’s one thing to turn a flag on or off, but who gets the flag which way? Here are some common approaches:
- Role: e.g., admins and developers only, versus everybody.
- Cohort: e.g., existing users keep the old way; new users get the new way.
- Geography: e.g., this country gets it this way; others get it the other way.
- Ramp-Up: This percentage of users gets it now, and we’ll adjust the % over time.
- Random assignment: The A group gets it one way, the B group gets it the other, and we’ll look at the data to decide which to keep.
Conclusion
Shipping every release is one way to take advantage of incremental development. But if you need finer-grained control over what is released when, consider the backroom/frontroom approach. This lets you make tradeoffs in areas beyond “Is the feature ready?”
References
Competitive Engineering, by Tom Gilb. Elsevier, 2005.
Design Patterns, by Erich Gamma et al. Addison-Wesley, 1995.
“Feature Toggles (aka Feature Flags)“, by Pete Hodgson. Retrieved 2021-11-01.