Naked Planning Explained – Kanban in the Small

While attending Agile2007 I kept finding myself in the company of Arlo Belshee, especially as he was going through his implementation of a Kanban System at BlueTech LLC. The conversations became for me one of the stand out ideas discussed at the conference.

This process might have started when Arlo really got in to the lean literature and looked around for waste in the Scrum system. He believed he found it in estimation. The amount estimated to work always differs from actual amount worked, is therefore supposition and only a guess, so this estimation was declared muda. There are a few different references on the matter, including Dave Anderson, Mary Poppendieck, or Amit Rathore. Even NetObjectives weighs in with a course offering.

The idea of the variable length Product Backlog with the need to reorganize priorities and estimate size was replaced with a fixed-length queue placed on a whiteboard for the Product Owner (Customer) to fill with Minimal Marketable Features (MMF), or what in Scrum would be User Stories. The length of the queue is seven, as this is believed by Arlo to be about the maximum amount of items any one person can hold in their head at a time. The slots are marked with permanent marker. Since the Product Owner trusts the team to do the work, the team believes these features to truly be: minimal, as anything less would not be marketable, which has immediate value for new or existing users.

The customer is allowed to rearrange these 7 MMFs as often as is seen fit. When the team is ready to pull a new feature, it is whatever is currently at the top of the stack. The 7 MMFs must fit to one of two goals on the board. When entering a new feature, the customer determines if the completion of remaining MMFs in the queue would satisfy the goal. If so, a new goal can be added to the board and if not, another MMF to satisfy the goal is added. There is one expedite slot for the customer to override WIP, anything else has to wait for a slot to open.

Releases can occur any time any one MMF is finished, as there is an ability to hide Work In Progress on the production site. The customer also has an idea parking lot for the overflow from these 7 items, or for other goals. An approximate wait time of when a feature may be released is added to the bottom of the board. MMFs are dated when they are placed on the board, and when they are finished to derive the average time of a feature. Significant changes in the size of work which effects throughput trigger a recalculation of this lead time. Arlo calls it the “approximate Disneyland wait time”, and is a statement such as, “Your expected wait time today from this point is between x and y days.”

The engineering team has 4 slots for WIP. This was determined because there are 8 engineers who pair all code. A majority of the board is reserved for information related to the work. This could be an article on competitive analysis, CRC cards, an individual engineers task list, or anything else deemed interesting to the work at hand. Stand-ups happen multiple times per day and are short. When the team switches pairs they ask if there’s any significant increase of information of note which is not on the board.

The amount of information for a task crescendos and then as it starts to taper the customer is asked if this meets expectations. Sometimes the information arrival increases again after that, but then the information stops coming in and all tasks are complete and the customer is reviewing the MMF on the production machine. Every Friday is a trade show of all released MMFs, and is a very jovial time in the office, a celebration of a job well-done.

15 thoughts on “Naked Planning Explained – Kanban in the Small”

  1. I think that you, Arlo, David Anderson and many others completely miss the point of estimation meetings. Estimation meetings are not primarily about getting estimates, that is simply a side-effect. The meetings are about getting a common understanding of stories, they are about collaboration. These meetings are an opportunity for team members and the customer/PO to share knowledge and understanding, to ask questions, to discuss design ideas… to build good software!

    Get rid of waste, for sure, but don’t throw the baby out with the bathwater.

  2. Hi Tobias,

    I’d like to think that I do have an idea about the point of estimating size to derive duration. This was the first great ah-ha moment I had with Agility delivered straight to me from Mr. Cohn. With his training, some coaching from Pete Behrens and advice from them both, I was able to “Scrummify” an organization and get to that place of very accurate prediction, as well as the collaboration. Check it out: http://www.scrumalliance.org/articles/71-predictability-in-action
    and please feel free to leave a comment there as well.

    thank you,
    Aaron

  3. Aaron, this time you missed the point of my comment ;-)
    I was saying that the purpose of the estimation meeting has little to do with numbers (size, duration, whatever) and much to do with collaborative dialog. Arriving at the number is simply a way of closing the discussion to move on to the next story. Good dialog is not waste.

    Further, making a sprint commitment based on a gut feel takes 1-2 minutes for a team. Hardly waste, even it turns out to be wrong.

  4. Tobias, I’m not missing the point of the value of estimation. I am, however, questioning how much value that actually is, and pointing out that there are a lot of costs. The time spent making the estimate is certainly the smallest cost.

    I commonly hear two sources of value for estimates. The first is to enable cost/benefit tradeoffs during prioritization. The second is that it forces thinking through design, to some degree, during the moment when the customer is present. I challenge the validity of the first, and acquire the second in a different way.

    I’ve got some math, experimental evidence, and a diagram that show that, in software, you get better results by prioritizing based solely on value than you get by including cost. This is because software is a highly-leveraged domain where cost is distributed linearly and value is distributed exponentially. I’ll be happy to talk about it with you sometime, but this comment space is too short.

    I do my design much closer to the moment of implementation. Because I don’t need estimates early, I don’t have to do any design early. This lets me force a design activity right at the moment of implementation. During planning, I just make sure that the appropriate people will be available during the week. And so we have this discussion at the latest responsible moment, when we’ve got more information. And we never have a design discussion about a story and then forget about it for several days while working on other stories.

    The main costs caused by estimation are a mismatch between uncertainty and people’s perception of uncertainty (one of the cognitive illusions), an incresaed amount of work in progress, a decreased flexibility, and a decreased ability to make honest and accurate projections.

    WIP: People believe, at a subconscious level, that you are working on anything for which you’ve had a design discussion. the task has become yours. Regardless of anything that anyone says, once you’ve had that discussion, you’ve promised that you’re working on their thing. And you don’t want to promise to work on 8 things at once, so you shouldn’t have that discussion about something until you’ve shipped the thing before.

    Projections: without estimates, I am reduced to only being able to use measurement to project the future. I can’t say “well, we learned from the last one, so this’ll go faster”. All I can say is, “well, given the way we work and how we plan, items below queue slot 3 never get done. Those that enter the queue at slot 3 take 3-5 weeks until they go live. From slot 1, it is 1-2 weeks to live”. Much less precise, but much more accurate – and actionable by the planning people.

    And, I never spend any time tracking estimates, improving the team’s ability to estimate, applying math to counter the effects of holidays & sick days, etc. This estimation normalization stuff takes a surprising amount of time – as I only discovered when I stopped trying to make halfway-decent estimates.

    Possibly most importantly, eliminating estimates eliminates conversations like “you promised that, this week, you’d do X, Y, and Z. Where’s Z?” Instead, the conversations become “What is the relative importance of X, Y, and Z? Well, X, then Y, then, eventually Z. Can we just release X+Y as soon as they’re done? Sure. We’ll give you some warning when the release is coming close.” It opens up a lot more success opportunities, and shuts out several types of bad behavior.

  5. There are great points in Arlo’s comment and his ideas about estimating and the waste related to that.

    I also listened to Arlo’s podcast with Bob@electroglide: http://agiletoolkit.libsyn.com/index.php?post_id=400364 Definitely worth listening to if you are interested in this topic.

    Maybe another argument that should also be mentioned is that in a study discussed in Peopleware by Lister and De Marco, it was found that “the highest [software development] average productivity was on those projects that didn’t estimate at all.

    The ultimate argument against (predictive) estimation is perhaps still to come, but one thing is for sure: there’s a lot more time and thinking going into that in our industry today then there should be. Other problems are much more important and relevant when it comes to improve communication (Tobias’ argument) like the fact that many teams still are distributed even if there is no business reason for that.

  6. Sounds interesting.
    I can see how this can work on a scope based project.

    What about time based projects?
    Simply imagine, that a customer calls and wants a new ‘take me to mars’ functionality, then wants to know how much will it cost and when can it be delivered, because time is of the essence.
    We have never implemented a feature of such complexity (…and most probably never will), therefore I don’t have a clue on the effort needed.
    What am I to say? Wait until we implement it and we’ll know when we get there?
    Obviously I can not take the “approximate Disneyland wait time” as you call it.
    I don’t see it.
    Am I missing something?

    In my opinion some initial problem analysis and rough estimation is still needed. At least to see if it is doable or not. And I don’t see anyone more competent to ask than development team.

    1. You should probably tell them to go elsewhere if travelling to March is beyond the expertise of your company. You should absolutely not give them a fixed cost/fixed time idea, if taking extreme risks are not part of your companys business.

      Taking someone to Mars could probably not be looked at as a feature growth in the small scale of assigning a few developers and start off an iteration. You need experts in the field, a large-scale project defining the extreme lead-time stuff and then, probably, you can give the customer a rough idea of the cost & time frame (no locks here, just ball park figures). If that is in the range of acceptable, you should start an agile process with the customer to get there, with the possibility to terminate gracefully if things are not developing to the customer’s contention.

      On the sub-sub-feature level to building your Mars traveller, one could skip the estimation – as is suggested. The aggregation of all estimates (if done) will not be of any value to predict the outcome of the total project.

  7. There is a lot of goodness here.

    I am a big believer in estimates are almost an antipattern in the world of development – as soon as you have a date or a number of hours, you guarantee only schedule slide – because no one is looking to do any better than that number; add a bunch of mediocrity and you get more and more slide. A predisposition for real action and discovery, for learning and building – over pencil-whipping bad bets… is the right instinct.

    The idea of 7 MMFs talks to the idea that MMFs can (usually) be identified. (This fits new product development, single customer consulting, and emerging products perhaps better than large foundational infrastructure – but you can still name minimal deployable units or some variation on the concept. And you should never isolate the team from the real customer/domain understanding – be it internal, commercial, public-service, whatever… the better the connection with the ultimate system consumers, the better the systems )

    That magical number 7addresses limits around short-term memory and human cognition… we can not manage too many things in our head intelligently. (the more common concept is 7 plus-or-minus 2) I do also think that a team seeing a monstrous backlog is a daunting thing and a distraction… it is easy to feel overwelmed or less hopeful if too many things are piled in your “inbox”. Insulating from this is mostly good. (long-view product concepts should not be hidden, but clouding todays goals with too much of that distant horizon conjecture is a barrier to good motion)

    In the enterprise world – I think much of this is difficult to apply directly – but by extension you can come up with ideas for delivering in the large. Sometimes there is not so much a customer as there are initiatives – and dependencies(lots of big ones); there are things strategic and tactical – infrastructure and customer facing – and plenty of yummy legacy sludge. There are too many teams scattered across too much work. If your system has 17 major systems – lets say at the level of an SAP – and business processes / customer systems are a complex interplay of these – it is naive oversimplification that this approach is a direct fit. Arlo makes no such declaration, of course. But I still think his ideas a decent milepost, regardless.

    Enterprises are usually big, complex, crufty, humbling hairballs… But I presume to think our ideas at this small team and project level might be extended to evolve larger organizations, their systems, and their processes. The norm for these big organizations: large complex systems, unwieldy process to match, and something akin to organizational constipation. (An inability to do any kind of profound change or productivity because mediocrity and stodginess are “designed in” and reinforced)

    But from ideas of the lean/agile/process world, from the domains of engineering and systems thinking, and the world of management and performance consulting, I believe a reference model for an agile enterprise can be identified. I think that the tools for agility in the large can be identified, the paths to realization can be mapped out, and antipatterns mapped to countermeasures. At the end of the day, being risk-averse, unable to really change or communicate, unable to garner their forces and line up on a vision (the human aspects of the problem)… are the only deep barriers for enterprises. That is… the big enterprise challenge is bold commitment.

    I know this to be a solid approach for small agile team success – Bravo, Arlo. The clarity and simplicity of Naked Planning – I like having this tool as a reference for gaging the strength of my own tooling ideas; Getting this kind of thinking into an enterprise toolset – I can only say thank you to Arlo for reinforcing the hope and belief that we can always make things simpler. [ Not that I have not challenged myself a bit wanting such things for the enterprise world :-) The enterprise belief in their own "sophistication" will likely only yield to ideas profound in their simplicity]

What comments do you have?