Brad, a program manager, felt torn. His management wanted the entire program to plan once a quarter and commit to the plans. The teams, including the product owners, wanted to commit to much less and be able to replan.
Brad wanted the benefits of the program’s agile approaches, being able to replan when necessary. He also wanted the program to move to continuous delivery. They weren’t quite there yet because the stories were too large.
The stories were too large because a quarter’s worth of work was too much for the teams to estimate well. The teams overestimated what they could deliver in a quarter, so they felt under considerable pressure to push features through. Those features weren’t quite done, they didn’t quite have enough tests, and the not-quite-done work always returned to bite them later.
Brad wanted to change things. He wanted easier planning that would allow them to change, as well as reliable continuous integration and testing of finished features. He suspected that once the teams could really get to continuous integration and testing, they would be able to move to continuous delivery.
He decided to ask his management to change the cadence of planning so they could plan more often.
Get TestRail FREE for 30 days!
Change the Planning Cadence to Manage Change
Brad had a monthly meeting with the operations committee. He decided to explain the problems to them.
He explained that when they planned for the quarter, they made these assumptions:
- All the feature sets have an even distribution of features—that is, feature set A has the same number of features as feature set B
- The value of all the feature sets is similar
- The arrival rate is predictable for all features
- The teams could properly estimate what they can finish in one quarter.
Brad had some data refuting each of these assumptions. He used the example of diagnostics and search.
Their diagnostics module had 24 stories. If the diagnostics team implemented the first 12 stories, they could cover enough of the common failure points that the team could stop there and move to another part of the product.
The search module had only 16 stories. But three of them were related to performance in different scenarios. Those three required experiments to know if the performance changes would work.
Brad explained that allowing the diagnostics team to finish the first 12 stories and move to another part of the program would help increase the overall product value. The company could charge for the release, even if the team hadn’t finished all the diagnostics stories. Over the next few months, the team could deliver a story every couple of weeks, and that would be fine.
In the meantime, the diagnostics team could work with the search team on the performance issues. The diagnostics team had special expertise in logging and instrumenting the code. The search team needed the help in order to reduce the time to experiment with the changed algorithms.
The operations committee was surprised. They hadn’t realized that some features were much more valuable than other features and that they didn’t have to have all the features to be able to release and recognize revenue.
They asked Brad what he wanted to try in order to manage the varying needs for releasing features.
Brad explained that he wanted to replan on a shorter cadence. He suggested they move to rolling wave planning. He thought he could provide a six-week wave. They would plan for the first six weeks, and as they finished a week, they would add another week to the end.
Rolling Wave Plans Offer Flexibility
The six-week wave worked better for the teams. Several teams were able to deliver a few times a week. However, too many teams were still trying to estimate what they could do in a given six-week period.
Brad asked the product owners to move to a four-week wave. That was better, until the marketing VP had an emergency.
A Very Important Customer needed a feature done by next week. Could the program deliver it?
Brad said they could, but there was a problem. The program wouldn’t meet their commitments if they moved features to accommodate this request. Brad explained that their rolling wave planning contained their changes.The program still had to commit for an entire month at a time.
Because they planned for less time, the work was smaller and the estimates were better. The estimates still weren’t perfect. The teams still felt pressure, although not as much.
Brad said, “There’s another alternative. We could embrace change, not contain it. That would require continual planning. It would mean no commitments to anything specific, but a commitment to deliver the most valuable thing every day.”
The marketing VP said, “This commitment business is just stupid! I’ll fix that.” He explained the problem to the operations committee.
Brad explained how continual planning worked. “We create a kanban board, with the ‘must have’ at the top of each time period. We don’t fill the time period. We use minimum marketable features (MMFs) so we deliver a coherent story to the users. We have to know what’s enough for a release.”
One member of the committee asked, “How do you know what’s enough?”
Brad said, “We need to have the product owners work closely with the teams to both define small stories and know what’s enough.”
Here’s what a picture of this looks like:
© Johanna Rothman
Brad explained that they were pretty sure what they could do in a quarter and that they could think about what was the minimum for a release.
One of the committee members asked, “What about continuous delivery? I thought that was something you were trying for.”
“I am,” Brad said. “My goal is to make all the features in the MMFs small enough to deliver at least one every single day. I figured you would love to have the problem of how to get people to pay on a regular basis if I could deliver something every day.”
They all nodded their heads.
The committee was nervous, but everyone decided to try it for a couple of months to see what happened.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Continual Planning Encourages Change
Brad’s program didn’t succeed right away. Some of the MMFs were much larger than anyone had thought, and some of the management team was worried that they couldn’t tell precisely what was on the roadmap and when they could expect it.
But then, several things changed.
The product owners felt forced to make much smaller stories. Several of them decided to have a contest to see how many days they could create one-day or smaller stories. Those small stories allowed the team to work together better, sometimes swarming and sometimes mobbing, to deliver finished, fully tested stories every day.
About a month into this experiment, about half the program was able to deliver features to the customer base every day. After an additional three months, the entire program was able to use continuous delivery.
Releases became something sales or marketing needed to discuss. The technical teams didn’t need to think about releases because they released every day.
The operations committee stopped asking for commitments. Instead, they started to discuss the value of certain features over other features.
Keep Planning Small
Brad also found other benefits of keeping the planning small. He never had to arrange for everyone to gather in a big room for planning. Teams spent much less time planning, and the teams saw their interdependencies much easier because the feature sets were more clearly defined.
If you want to embrace change instead of contain it, consider continual planning. It’s not for everyone. But if you need more change, try it.
This article was written by Johanna Rothman. Johanna, known as the “Pragmatic Manager,” provides frank advice for your tough problems. Her most recent book is “Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver.”
Test Automation – Anywhere, Anytime
