Estimation and Waste

There’s been some discussion recently on InfoQ and in the XP Yahoo! Group, as to whether estimation could or should be considered as waste.  My recent view has been that estimation is waste, but I think I am refining that position to be that “traditionally recognised” estimation is waste, and that there are subtleties which mean that some sort of estimation still has value.  I’ve put together the following 3 differentiations about how estimation fits into a kanban system for software development.

  1. Estimation can be implicit.  Traditional estimation usually involved some sort of explicit meeting or event where the estimates are determined.  The most common Agile format is Planning Poker.  An alternative technique which use a more implicit format are aim for each work items to be equally sized, thus reducing variation and enabling smoother flow.  Obviously, in order to figure out if items are equally sized, some form of estimation must take place.  Amit Rathore has written about this.  Similarly, a basic classification could take place, such as T-shirt sizing, in order to determine relative sizes.  In both these approaches, however, the focus is on measuring and improving throughput and cycle-time, rather than making planning predictions.
  2. Estimation can be course grained. The granularity and precision of estimates is relevant.  A common concern with ‘estimation-less’ development is how forecasts of time and cost can be made.  This forecasting can be made without story points by working at a higher level, and focussing on what goals can be met, and what problems can be solved.  This can probably still be considered to be an estimate, but its very low granularity, low precision and more ‘gut feel’.
  3. Estimation can be about quantity.  Estimation shifts from asking “how long” items will take, to “how many” items can be done in a time-frame.  By measuring throughput and cycle-time, this estimation becomes much more measurement based, assuming you have either same-sized, or categorised items as described in point (1).

All in all, estimation is a means to an end, rather than an end in itself, the end being reliable forecasting and delivery of projects.

Traffic Jams

One of the metaphors I use when I talk why a kanban system has work-in-progress (WIP) limits, is traffic jams. The greater the WIP, the lower the throughput, and this effect can be seen when too many cars clog up a motorway. Watching the BBC’s “Britain from Above” last night, they had an interesting section on this subject, including a nice simulation on how a bottleneck ripples back as it frees up, explaining how traffic jams can seem to appear and disappear for now apparent reason.

You can seen the clip here – the simulation is about 3 minutes in.

I expect you get the same effect in software development value streams, although I would also expect that software development value streams are short enough for the effect to be unnoticeable.

KFC Consequences

One of the regular questions I get asked when I talk to people about KFC Development is about how it is different.  As a result I came up with a set of KFC Consequences to try and help articulate this.

  • Kanban Consequence – Eliminate backlogs, timeboxed iterations and estimates.

Eliminate might be a slightly strong word, but there is certainly less reliance on these things, and thus less wasted investment in them.  Ultimately a high performing team would not need them in a typically recognisable form, although they may use variations.  For example, an ‘incubation area’ might replace the backlog as a simple place to keeping ideas before they are refined into MMFs.  Similarly, classification might replace estimation.

  • Flow Consequence – Use larger, value focussed features

Rather than an emphasis on driving user stories into smaller and smaller pieces, there is more of an emphasis on right-sizing pieces of work based on their value.  User story decomposition is used more as an analysis technique.

  • Cadence Consequence – Commitment via measurement and SLAs, rather than planning and timeboxes.

Instead of planning batches of work into timeboxed iterations as a mechanism drive productivity and commitment, the mean lead time of MMFs is measured and used as an SLA against which due date performance is reported.  Thus it is actual performance which drives productivity, rather than forecast performance.

Predictability v Efficiency (or not)

Allan Kelly blogged recently about whether kanban systems trade predictability for efficiency.  Its an interesting viewpoint, but I’m not entirely sure I agree!

Firstly, I don’t believe any agile process gives predictability.  One of the reasons for preferring agile methods is that software development just isn’t predictable.  Rather, I would say that agile methods can give reliability and that both kanban and more traditional agile methods give equal reliability.  Secondly, I prefer to focus on effectiveness rather than efficiency and that both agile and kanban value effectiveness over efficiency.

So, if there is a trade-off, it is between the amount of up front effort in planning in order to achieve reliability at the expense of effectiveness.  Scrum (for example) invests time in Product Backlog and Sprint Backlog planning in order to communicate at a high level what should be delivered.  Thus Scrum says “we believe we will deliver this much work over that time period, and that it will be made up those items”.  Kanban, however, simply measures average lead time and due date performance.  Thus Kanban says “we belive we will deliver this much work over that time period *but* we don’t yet know what those items will be – we’ll decide at the last responsible moment”.

Actually, I thinks its more a relationship between trust and effectiveness.  The more mutual trust there is between the business and delivery team, the less up front planning is needed, and the more efficient a team can be.  That’s not to say that Scrum has a heavy up front planning process, or is a low trust method, but Kanban takes advantage of more mutual trust in order to eliminate some overhead and be more effective.

XP2008 – Day 2

I went to Jeff Patton‘s tutorial on User Story Mapping this afternoon.  I first met Jeff in London last year at XP Day and the Scrum Gathering.  We talked about kanban, and his ideas, and the two seemed very compatible, so I was keen to see how they matched in more detail.  Jeff has also been working with former Yahoo! colleagues Joe Arnold and Aaron Sanders on a kanban related article, so he also sees a connection.

Jeff is trying to solve a number of problems with User Stories that I’ve also seen:

  • they are difficult to prioritise because it is usually a collection of stories that provide value.
  • it can be difficult to understand the dependenies between stories.
  • it can be difficult to understand the whole system from a backlog of stories.
  • creating more smaller stories makes the above even worse!

Jeff’s solution is to break a system down into the following hierarchy:

Goals -> Activities -> Tasks -> Tools
  • Goals are the user centred things which are trying to be achieved
  • Activities are role based themes of functionality
  • Tasks are more specific, but still high level features, which make up an activity
  • Tools are typical more detailed user stories

By creating this hierarchy and generating a physical map using index cards, the relationship between the various parts of the system, and the value that they are delivering, can be communicated and evolved.  Activities form the ‘backbone’ of the system, and Tasks can be prioritised to form a ‘walking skeleton’, or a ‘fully formed, but immature’ system.

From a kanban perspective, it seems to me that the Tasks are similar to MMFs, and are what make up the kanban cards, and that the Story Map is a tool to inform both the value that they generate, and the order in which they should be scheduled.

XP2008 – Day 1

I’m at XP2008 in Limerick this week. Today was pretty quiet as its all tutorials for the first couple of days, which cost extra, so I didn’t actually go to anything. However, I did hang around and catch up with some old friends.

In particular, I had an interesting chat with Tom Poppendieck about my experiences with kanban systems. Tom felt that while a kanban system was great for small pieces of work such as sustaining engineering, it wasn’t so suitable for larger pieces of work such as new product development. This is counter to my experience that a kanban system using larger MMFs as the kanban actually helps the focus on delivering value with a reduced cycle time.

While generally talking about Lean, Tom also recommended a new book, Ready, Set, Dominate: Implement Toyota’s Set-Based Learning for Developing Products and Nobody Can Catch You by Michael N. Kennedy, Kent Harmon. Another one to add to the reading list.

Upcoming Conference Presentations

I’m really pleased to have had a number of submissions accepted for various conferences this year. I’ve added details onto my Calendar page.

In particular I’ve had 3 talks accepted for Agile2008 in Toronto, one of which is a workshop called KFC Development. I’m really looking forward to sharing my thoughts and getting feedback from attendees which I hope will help clarify the ideas.

Agile North Spring Mini Conference

I gave a short presentation at the Agile North April Mini Conference last Saturday. It was a great half day, and possibly the first Agile conference without any reference to Scrum or XP! Just Real Options and Kanban with Portia Tung, Pascal Van Cauwenbergh, David Anderson and myself.

I’ve added my slides to the downloads page. The talk was also videoed, so that may appear later aswell.

Unfortunately, we all had so much to say that we ran out of time, and I wasn’t able to play my “KFC Games”. Actually, they’re more simulations than games, but here’s some links to what they involve in case you want to try them out anyway.

KFC Development

I’ve been referring to my latest thinking on development process as KFC Development. Its a bit of a gimmicky name, which makes it memorable, but there is some meaning behind it. KFC stands for Kanban, Flow and Cadence – three lean concepts which I think are important and complementary.

Kanban – Kanban is the mechanism which controls the workflow and helps manage inventory and investment, and identify bottlenecks.

Flow – More specifically One Piece Flow. The one-piece is a Minimal Marketable Feature (MMF) which ensures there is focus on the delivery of actual value. This avoids the temptation to artificially break work down into smaller chunks in order to fit them it into an iteration or sprint. A side effect of this flow, is that typical agile time-boxed iterations can become unnecessary.

Cadence – Cadences give the team the rhythm usually provided by time-boxed iterations. There can be a variety of cadences, from daily stand-ups, to quarterly roadmap planning. An additional cadence is that defined by cycle-time, which determines throughput, and allows a level of forecasting of future work.

I’m hoping to explore these ideas more in the future.

Kanban Commitment

In a recent post on kanban-esque scheduling, Brian Marick asked whether using a kanban system to manage software development has enough discipline, and in particular whether there is enough commitment to deliver. I’ve been working on ways to answer this, and recently came to a conclusion, when David Anderson reminded me that Corey Ladas has already said the same thing, which he described as striking a different bargain with the business.

To put it in a nutshell, rather than making commitment on an iteration/sprint/time-boxed basis, you make the commitment on a feature by feature basis. In other words, when a Minimal Marketable Feature (MMF) gets scheduled, you agree an SLA for when it’ll be delivered. As Corey has already explained the concept so well, I’ll instead describe how I came to the same answer.

When we were using a more Scrum-like approach, we make a forecast of what we could deliver on a Sprint by Sprint basis, along with a longer term forecast using the Product Backlog. However, moving to a more kanban-like approach meant that there were no time-boxed forecasts, and the Product Backlog became just a list of things to do no prioritisation and forecasting.

But the business, however, still wanted some idea of what to expect in the coming months, so for the last two quarters, we’ve tried to put together a high level roadmap. The kanban approach meant that we didn’t want to invest much in analysing and estimating a Product Backlog up front. Instead we identified some key MMFs and did some simple T-Shirt size estimates, and based on our historical velocity we plotted out what we thought we might deliver in each of the following three months. This was very quick and high level, such that we planned for Q1 this year in under 2 hours. What we have actually delivered, however, has turned out to be very different due to the usual changes in circumstances and priorities.

That’s a fairly clear indication to me that even such basic estimation in advance is wasted inventory. So how do we set an appropriate level of expectation with the business so that they know when they might get a feature? Cycle time and throughput help, but when MMFs are of varying size, the calculation of when to prioritise can be complicated. On one the Agile mailing lists, Alistair Cockburn recently described the purpose of planning to be able to answer the question “With what we NOW know, what will the most useful system we can create look like on THAT date?” and that’s when it occurred to me that an estimate is just a way of setting an SLA with the business so that they have confidence that if we start something NOW, then it will be done by THAT date.

As a result, estimation can be done in a lightweight way at the “last responsible moment” in order to set an SLA with the business. The last responsible moment will depend on the criticality of the feature. For a more critical feature, the SLA may be required earlier in order to ensure it can be prioritised soon enough. For a less critical feature, the SLA may only be required when it as actually scheduled.

To get back to Brian’s concern then, the discipline and commitment is because the team is saying, as Corey puts it, “When we agree to take on a work request, we intend to deliver it within n days“.