To produce the most value from your available resources in your allowed time, release first the part of the system that is truly necessary to have a viable business product. Restrict the time you allow for building this core part to only the time your estimates say it needs, and don’t use all of the calendar time available. 

Main Points

• You can find predictability in software work.
• A way to identify the core part of your system.
• Ways to estimate how long it will take to do that work.

High-Level Release Planning – Pareto versus Parkinson’s

If proper release planning is the way to get the most from our resources, how can we do high level release planning with Agile methods? Many Agilists have assumed software work is not predictable enough to make this practical. Fortunately, they generally track the velocity of their software work, which is one of the main things you need to know to do effective release planning.

Much of the confusion about predictability in the Agile space is due to a confusion between micro and macro predictability. Micro-predictability means I can’t say what color will show up on the roulette wheel.  However, macro-predictability tells me that more money is staying on the table than is leaving.  While predicting specific, small things may be difficult to do, higher level predictions can often be reasonably accurate.

Those who use a Kanban approach have a different problem: They tend to not track velocity. Either of these attitudes makes it seem that release planning will be difficult.

Yet, it is both possible and even simple, with either Agile approaches or with Kanban, to both achieve a level of predictable work throughput and to do effective release planning.

How Release Planning Applies to Kanban

Even if you are using Kanban, you can estimate your workload and predict reasonably well at a high level.

There is a lot of confusion about how this kind of planning applies to Kanban[1]. While Kanban typically does not use iterations like most Agile methods, they can be used if it is desirable[2].

Even if you don’t use iterations in Kanban (which is usually the case) most practitioners apply the notion of cadence. And having cadence lays the groundwork for release planning.

Cadence means to have a regular beat of intake, demonstration and output.  For example, you can have your customer (or their proxy) update what’s on the backlog weekly (that’d be a weekly intake cadence).  You can also demonstrate what your team has done every week (that could be your demonstration cadence).  You might release every two weeks (your output cadence).  Kanban doesn’t require that all of these cadences be at the same time, but it does highly suggest having a cadence.

Estimation: The Other Main Input to Release Planning

Estimating the amount of work to be done is another practice necessary for planning releases. This is another area sometimes relatively overlooked in the way Kanban is typically done. But it can be done just as well in Kanban as in traditional Agile approaches.

Release planning requires estimating the work under consideration.  There are several reasons for this including ensuring a common understanding of the feature being worked on.

The real challenge we find people have is not that estimation is truly wasteful as it is that people use less efficient methods than what are available.  For example, we’ve found that Steve Bockman’s Team Estimation method takes one-third to one-tenth the time of Mike Cohn’s Planning Poker.  We’ve not used James Grenning’s planning poker but it’s much closer in style to Bockman’s approach than it is to the similarly named approach by Mike.  See ‘Estimation in Agile: A Conversation’ (pg 39) from  Lean-Agile Pocket Guide for Scrum Teams for both more on why estimate and also how to do Steve’s estimation method.

An Example of Effective High-Level Release Planning

The planning method below assumes you are estimating the features you are going to build. I like to explain things with an example. A few years ago we were working with a development group of about 300 people.  They were part of a larger product group of about 1000 people. This group was part of a product line of about 3000 developers.  The group of 300 was creating a significant update to their current product.  Near the beginning of the project we delivered an Lean-Agile Enterprise Release Planning course to a cross-section of folks from the development group. They consisted mostly of product managers, product owners, architects, technical leads, managers and analysts.

The course starts by mapping out all of the features that are expected to be needed.  We typically orient these in a left to right fashion where the further left things are, the higher in importance they are.  In this case we had about 4 rows of 4”x6” stickies on the wall.  Each stickie represented a minimal-marketable-feature[3] that needed to be built.   I don’t remember exactly how many stickies we had, but I remember they covered a wall for about 15’ – a lot of stickies.  They were in four rows because the development group had to support four different platforms – Windows, Solaris, AIX, HPUX.  We hadn’t decided whether we should build the product for one platform completely and then build the other platforms so we merely put platform specific items on their own row.  The stickies looked something like that in Figure 1.

[Figure]

Figure 1. Stickies representing the features  to complete in 10 months.

The course was taking place in January and the project was to run ten months, based on high level estimates.  There were valid business reasons why they were not going to release the product in stages – which I won’t go into here.  After laying out all of these features I asked a simple question – “How many of you have no doubt that you will get this completed by the end of October deadline?”  As I expected, no one raised their hand.  Then I asked a different question – “Which of these features do you have to have or you don’t have a product?”

This question emphasizes how there is a difference between what you must release and what you want to release.  They had been saying that the full set was necessary, but I knew that was not the case (it never is).  That what they really meant was that they needed the full set to keep up their reputation in the industry, but that a smaller set would suffice, albeit not as well, if they were behind schedule. The real problem with missed estimates is not that we miss the date. It’s because we can’t pare out the less necessary features so that we can focus on the critical ones.  We often get trapped by our false confidence in the date we open too many work-items and when it comes time to de-scope we’ve either already completed low priority items, or worse, partially completed them. This is worse because we get no value yet the incomplete state of the code greatly complicates things.

Asking the question “what do you need or you don’t have a product” forced them to think about the key, core functionality that was absolutely necessary.  The idea was to focus on getting that pat done.  I asked them to answer the question by drawing a vertical line on the board and put all of the stickies that had to be done or there was no product to the left of the line and those stickies that’d be nice to have on the right of the line.  I’ll admit I was very impressed when they completed this in about 15 minutes as shown in Figure 2.

[Figure]

Figure 2: Organizing stickies by ‘Must Do’ and ‘Nice to Do’

What advice do you think I gave the team now? Before answering that, remember, what’s the real point of planning? It’s not to work to the plan, it’s to help us get the most out of what people and resources we have.  By focusing on delivering true value and not sticking to the plan the thing I most wanted to avoid was having to have started or completed something that I would eventually want to de-scope.  Hence, I suggested that they now had a two phase project.  The first was to complete everything that was to the left of the line, which they estimated to be 7 months of work.  After completing that, if they had any extra time, they could work on the right side.   The question remained – “how much time should they allow for completing the left side of stickies?”  Parkinson’s law tells us that work will fill the time allowed.  If we said they had the full 10 months to do the critical stickies, Parkinson’s law would predict they’d use up all of the time doing that work, and possibly not even get all of it done. So the timeframe was – do the ‘must do’ stickies in seven months.  Now they would at least know they had a product.  If they ran late they had three months buffer to get it completed.  If, on the other hand, they did get it done, they could iteratively build the rest of the stickies. It’s important to realize, by the way, that although they were not going to release for 10 months, they were definitely intending to build in stages.

I call this approach “Pareto Vs Parkinson’s” because it pits Pareto’s insight that 80% of the value comes from 20% of the work against Parkinson’s law that work will fill the time allotted.  While we weren’t really getting 80% of the value with 20% of the work, the idea that one should focus on the most important aspects of the work was the essential insight.

Epilogue

I checked back in with the company a few months after the project was to have been completed and was happy to hear they had met their schedule. They completed both segments pretty much on time.  Much of the reason was that the approach they took had them focus on the most important parts of the system. Notice that whether they used Scrum, Kanban or even Waterfall (they used mostly Scrum) did not matter as much as breaking the work down into the most important parts and building iteratively.  The high view of keeping all the teams focused on the same work by not breaking all of the work up and giving it out to teams had a tremendous focusing affect.  Furthermore, it was nice that we didn’t have to learn the problems that we would have ran into trying a pure bottom up approach, the learning and removal of which may have had us miss our deadline.  By taking a high-level view, we were able to set ourselves up for success.

An additional benefit of this approach is it has proven helpful for jump-starting a non-Agile team into Agile by having them focus on smaller business chunks being built at any one time.

Summary

Often the way Agile is implemented is to treat a major product release as a “take it or leave it” whole. Then the whole product is broken into many small pieces without much thought giving to the business importance of the pieces, and several teams build those pieces in parallel until finally attempting to integrate them successfully at the end of the entire development period.

A much better use of resources is to first identify the core functionality that must be delivered to have a viable product. This core part is allocated only the time that its estimated scope and the organization’s velocity indicate is needed to complete its development.

The remainder of the work in the original overall plan is given the remainder of the schedule, to finish as much as possible. This usually results in more being completed than would have been done without this division, with the additional benefit that the customer of the product receives value much sooner than the original schedule.

Footnotes

[1] See Demystifying Kanban if you’d like to learn more about Kanban. The definitive guide for Kanban is David Anderson’s Kanban: Successful Evolutionary Change for Your Technology Business.

[2] This hybrid of Kanban with iterations is sometimes called Scrumban. See Scrumban – Essay on Kanban Systems for Lean Software Development for more.  Many of the essays comprising this book can also be found at Lean Software Engineering, but I recommend just getting the soft copy of Corey’s great book.

[3] Discussed in the Delivering in Stages chapter. You can learn about them online at Minimal Marketable Fetaures: The Why of Enterprise Agility a Net Objectives lightning webinar.