What you will learn in this chapter
This chapter talks about the value of focusing on that part of the system that is truly necessary to have a viable business product. In particular it discusses how the core part of your product should be built before any other part of the product is built. This core part should be built in the time it needs, not using up all of the time available. This high-level approach can often get a team that is not doing Agile into a somewhat Agile mode by having them focus on smaller business chunks being built at any one time.
Background
People often ask me how to do high level release planning with Agile methods. Many agilists have talked about lack of predictability. Those who do Kanban tend not to track velocity. With either of these attitudes it seems release planning will be difficult. Our view, however, is that it is possible to achieve a level of predictable work throughput and, even if you are using Kanban, you can estimate your workload and predict reasonably well at a high level.
Before discussing how, I’ll need to first discuss some basics.
First off, there is a lot of confusion about Kanban. While Kanban typically does not use iterations, they can be used if it is desirable. But even if you don’t use iterations in Kanban (which is much typical than not) most everybody uses the notion of cadence. 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 2 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 is another practice many people doing Kanban don’t like to do. We, however, typically recommend 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 Bochman’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 Bochman’s approach than it is to the similarly named approach by Mike. See ‘Estimation in Agile: A Conversation’ (pg 79) in Lean-Agile Pocket Guide for Scrum Teams for both more on why estimate and also how to do Steve’s estimation method.
An example
In any event, the method I am about to describe assumes that you are estimating the features you are going to build. As you’ve learned by now, 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 feature 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 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 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 7 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.
A note about predictability (macro vs micro)
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.
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.