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“.