Most custom software projects have three major phases in their lifecycle. First, there’s the Build phase. This is the initial period of time when a platform is being designed and developed, which culminates with an initial launch (typically a Minimum-Viable-Product first launch or beta release).
Next comes the Grow phase: a period of time post-launch when you are still in active development, continuing to add new features, fix bugs, and fine-tune things based on user feedback.
Finally, there’s the Support phase. The software is considered “feature-complete” (at least for now), and development efforts are minimal, focused on bugfixes and necessary infrastructure maintenance.
For agile software teams, the Grow phase carries some special considerations, especially if you are using the same developers to add new features and respond to production support issues as they crop up.
Inexperienced teams and product owners may naively expect that development velocity during the Grow phase will be consistent with velocity during the Build phase. However, this is rarely true. In my observation, projects typically take a 5-20% velocity hit once the system is in production. This is a result of a few factors:
- Overhead from working with production data: When you’re in the Build phase of a project, it’s no big deal to dump your database and start fresh if you need to make significant changes to the data structures. However, when you’re dealing with real customer data, you can’t do that anymore. Migrating the data and taking precautions to protect it takes extra time and cost.
- Bugfixes: Bugs are inevitable. Even with rigorous usability testing, exploratory testing, and automated testing, adding “real” production users to the mix will expose bugs and edge cases that need to be addressed in a timely fashion.
- Tier 3 support: While we don’t provide helpdesk-style support for our customers’ end users, we do end up providing support for the everyday issues that our clients can’t figure out how to solve. You can expect that at least a portion of the team’s time each week will be spent diagnosing issues or figuring out heretofore unimaginable edge cases, sometimes resulting in a bugfix or a UI tweak.
Overlooking the “production software tax” of the Grow phase is an easy mistake to make, and a frustrating one. It can very quickly throw off project predictions, leading to stress as the team strives to reach the next few milestones.
Here are a few ways to avoid that stress and make sure your product launch and subsequent Grow phase is happy and productive:
1. Pick your launch target carefully.
When building your initial project plan and choosing target launch dates or milestones, respect the inherent “tax” that comes from working on production software. Launch day is exciting and every software product owner wants to start using or selling their new software sooner rather than later. However, launching earlier than absolutely necessary can have an impact on the overall bottom line, or on subsequent release targets, so it’s worth factoring into your plan and weighing the costs and benefits of different release dates.
2. Buffer your project plan during the Grow phase.
For agile teams using points-based estimation and backlog management tools, it can be tricky to track and predict how production support issues will affect your overall velocity and sprint plan. To account for this, I’ll add “buffer” stories to my projects to account for some of the overhead and support needs that inevitably crop up.
Here are some of the things I take into account when deciding how much buffer to add:
- Length of the Grow phase: For relatively short Grow phases, I might just have one large “production support” buffer and then break smaller stories out of it as time goes on. For projects with long Grow phases, I might create a buffer for each sprint or each month.
- Risk of the features involved: Particularly complex or risky features might get their own special buffer.
- Additional deployments: For some projects, or for particularly dramatic changes, you can expect increased support cases after a deployment. When this is the case, I buffer the deployment chore accordingly. Then, as support issues crop up during the Grow phase, I create bugs or stories in the backlog to track them and pull points from my buffers accordingly.
3. Buffer your sprint plan during the Grow phase.
Adding buffers to your backlog helps to ensure predictability in your long-term project plan. In some cases, you can guess when you’ll need your buffers (for example, when doing deployments). However, you can’t always predict when a critical bug will be discovered or when an urgent support issue will crop up, taking priority over feature work. These emergent tasks can wreak havoc with a carefully planned sprint.
To combat this, consider blocking off an amount of time every sprint as support time. The appropriate timebox will vary depending on project needs or sprint length, but you can arrive at a pretty good guess by looking at the overall percentage of time your team spends on support and bugfixes.
With a timebox in place, you’ll have time in your sprint when the urgent issues come up, and the team won’t feel as stressed about “not getting work done.” If you end up going an entire sprint with the happy day case of no urgent issues, you can use the timebox to take care of chores and infrastructure maintenance tasks, or simply begin working on the next feature.
4. Consider your resource plan.
In some cases, after the initial big push to build and launch a project, the team will be scaled back during the Grow phase, with the majority of the team members being redeployed elsewhere and a few team members staying on to continue adding features.
This can be a good move, but it’s important to remember that the resulting velocity decrease will be impacted not only by team size, but support burden. If you still have important post-release milestones, make sure that you don’t put those milestones at risk by downsizing the team too much. Similarly, if you want to keep the team going at full velocity because you have important post-launch milestones to hit, consider adding to the team in order to account for the production support tax.
By recognizing and planning for the inevitable needs experienced by a software project that is in production, you can have a successful Grow phase and still reach your milestones and release targets with your sanity intact. Launching at the right time, using buffers judiciously, and keeping an eye on your resource plan will increase predictability and productivity, contributing to cost savings and overall success of the product.