A couple of weekends ago I had the pleasure and privilege of attending one of David Anderson’s Kanban Leadership Workshops. Spending a long weekend with a group of motivated people openly sharing their wide range of experiences was a joy! It helped me to crystallise further a few thoughts that I have touched on before, and I write them down while they are still fresh in my mind.
I came away from that weekend more determined than ever to dispel the notion that the conventional project should be the default approach to managing and controlling software development work. My aim here is to show that a Kanban-based service delivery approach can accommodate the project plan when needed but has the flexibility to manage work that isn’t necessarily schedule-driven (most work, really) in a much more effective and transparent way. Moreover, it can work without sophisticated tooling and will serve very well as a mental model, guiding improvement and risk-management activities and informing those key interactions that take place at the sources of demand into your system.
And this is where we start.
On priorities and prioritisation
It is vital to have priorities, and just a few of them. Priorities (the themes or imperatives of your business or product) must drive a short list of items to be worked on soon; these are more likely to be found in the heads of your key customers than by grooming your backlog.
Getting to this “sufficiently short”® list in a robust and timely fashion is a high value (and ongoing) activity. Perhaps inevitably, it is also a rather context-specific one, so for the purposes of this article I will assume only that you have at least embarked on establishing such a process.
This is not to say that there is no place for lists, plans (conventional project plans, roadmaps, capacity plans etc), and analyses (of requirements, risks, markets, competitors etc), but that these are merely inputs into an agreed method for making a distilled set of prioritised work items available to the development team as and when needed.
Now inside the system, scheduling is the process – and it’s an ongoing and dynamic thing – of producing economically optimal results from the sequencing of work items. It’s a big responsibility, so let’s try to do it in a robust and transparent way.
Thanks to Don Reinertsen, I see in this context “economically optimal” and “minimised cost of delay (CoD)” as equivalent for practical purposes, and this has become my robustness test.
The transparency test is a little harder though, because delay costs are not always easy to pin down. Where they are quantifiable, they’re not just numbers, they’re functions of time; moreover they are often estimated more easily in “frustration points” or “difficult meetings” than in dollars! Fortunately, we can easily recognise different types of work items whose CoD functions tend to behave similarly. This turns out to be a very useful thing to be able to do, because the different types place different requirements on the system.
A rough guide to work item types
In increasing order of urgency, work items tend to fall into one of these four types:
1. Important but not immediately urgent – the “slow burn” work as I like to call it. Since the cost of a short-term delay is low for these items, it can be hard to resist the temptation to put them off, by failing to allocate effort to them or by shying away from make the case for them so that they never even appear on the priority list. But that would be foolish.
Our aim in managing these slow burn items is typically to achieve a combination of the following:
- Avoiding a future (but somewhat far off) pile-up of now-urgent work that would compromise our ability to deliver timely business value, potentially at a critical time. Medium-term capacity improvements and supplier-necessitated platform refreshes are good examples of IT-driven work that carries this kind of risk.
- To create future development capacity, to reduce future costs or to create future options. In other words, work that increases capability – whether people, process or platform-centric, local to the team/product or broader in scope, mainstream or experimental.
Given that timeliness is not a primary concern, it suffices that we ensure that we are delivering these work items at a suitable rate. This rate allows for the aggregate risk associated with the work items in question (e.g. to prevent a future problem), the need to protect and promote the long-term health of the system, and to provide a reserve of short-term slack in the system.
2. Increasingly urgent – the bread-and-butter work items that for many teams dominate the working week. Their common characteristic is a cost of delay – whether measured in dollars, reputation or frustration – that increases with each passing day. Typically their delay costs don’t merely increase linearly with time but have a nasty habit of accelerating up a steepening curve as the effects of compounding, lost opportunity, dependencies, competition, psychology and politics kick in.
From a system perspective, we look to deliver these items with short and reasonably predictable lead times.
3. Deadline-driven work items, where a sudden and material impact to the organisation will be the result should we fail to deliver on time. Unfortunately, many organisations overuse this category, either as a tool to “encourage” urgent work or unthinkingly as the default delivery model. Used more sparingly, coupled with a good understanding of capability, good upstream relationships and adequate notice, we would hope to deliver these on time with a minimum of drama.
The performance requirement placed on the system here is simple: don’t be late!
4. Expedited work items whose immediate value to the business clearly trumps other considerations, justifying the exclusion or detriment of other urgent or deadline-driven work. Customers might raise new items with this priority, or they could be generated internally (in response to an outage or a newly-discovered system vulnerability, say). Through risk management, we may sometimes choose to escalate existing in-progress items to an expedited status.
Here the performance requirement placed on the system is stark: expedite it (i.e. just get it done), on the basis of critical need!
Managing work with Kanban’s classes of service
Kanban’s classes of service combine scheduling policies with capability measures. Seen as a systematic response to the varying needs of the different types of work items we have discussed, they are actually very simple to understand and operate in practice.
- WIP under control (this is Kanban, right!)
- A “suitably short” list of work items to select from, i.e. the input queue
All we need to do is to do is to apply some simple rules when selecting work items from the input queue or from the internal queues between activities (again, this is Kanban: all else being equal we much prefer to finish something than to start something new):
- We pull an expedited item if there is one (assuming that we haven’t “dropped everything” already!)
- We take a deadline-driven item if failing to do so would increase unacceptably our risk of not delivering on time
- After that, we balance the rate of delivery of the “slow burn” items with the need for speed on the increasingly urgent items
Striking a balance is never easy under pressure; explicit policies to protect non-urgent work (medium term delivery rates &/or effort budgets) can be very helpful.
The table below summarise the needs of our work item types and how they map to the recommended classes of service in Kanban:
|Work item type
||Class of service
||Typical Service Level /
|1. Important but not urgent (“slow burn”)
||Items per month
|2. Increasingly urgent
||80th or 95th lead time percentile
||As soon as possible
Why it works (1)
In reality, work items don’t sit forever in fixed categories but move inexorably along a cost of delay curve that sits in a space rather like the one shown in the figure below. The shape of the CoD curve is unique to each item – driven by a combination of the time-sensitivity and business impact of the item – but they do share some common patterns. “Slow burn” follows “ignore” and migrates into “increasingly urgent” and perhaps “deadline-driven” as time passes and the cost of delay rises, perhaps steeply. Urgent and late items may be “expedited”. Failure may lead to “world of pain” or “diminishing benefit” then “missed opportunity” depending on whether the CoD function either continues to grow or declines over the longer term.
Our scheduling policy is designed to complete (at a minimum) enough non-urgent work to prevent pent-up demand later becoming an impediment to urgent work, to deliver deadline-driven work on time, and to accommodate a certain amount of expedited work without too significant an impact on other priorities. The remainder (a significant proportion if the demand is well-balanced) goes to urgent but not necessarily deadline-driven work. It is here where we expect much of the immediate business value to be delivered.
Why it works (2)
Kanban encourages us to make explicit both the scheduling process and its governing policies. It promotes upstream collaboration not just in the individual work items but in the overall mix of the demand. A balanced mix provides a degree of slack where it is most needed, so that short-term shocks can be absorbed and predictability maintained, facilitating medium-to-long-range planning. Performance transparency enables service levels and schedule risks to be analysed historically and managed proactively.
Hints & tips
- Don’t let anyone persuade you that the slow burn items of the kind I describe don’t have significant business value. Quoting (roughly) Ronald J Baker, “the value of an organisation or product is no less than its ability to create future value”. That said, a day’s slippage here or there isn’t a big concern, and (as described) they may be de-prioritised temporarily to create the slack needed to allow more urgent items to flow.
- You might like to leave some of your slow burn budget to be spent at the discretion of team members (but do discuss the risks involved).
- Sequence the “increasingly urgent” items according to cost of delay (or value, however measured) in relation to remaining lead time (delays included) rather than development cost. For a given set of prioritised items the overall cost expended will be the much the same regardless of how they’re sequenced, so optimising for it is pointless. Much better to pursue fast feedback on high value items.
- You can move items between categories as their risk profiles change.
- Less WIP and shorter lead times (which we know go hand-in-hand) means fewer opportunities for scheduling conflict. So much easier!
- And finally: I only hinted at the gold that is to be found upstream of the development process. Go find it!
A big thank you to David (@agilemanager) and his class of Feb ’11. My stated personal goal for that weekend was to explore and express service-oriented alternatives to project-based thinking.
And to @benjaminm, @AGILEMinds and @blubberplinth for their encouragement and thoughtful input as this article took shape.
The system is not limited to the development team – the scope of the system and its scheduling policies can grow to influence and encompass upstream activities too
 I reviewed Don’s book here
 Let’s not talk about unimportant work!
 Nod to Stephen R Covey and his 7 Habits here, hat tip @blubberplinth for the reminder
 I’m using here the names of the classes of service as described in David’s 2010 book, reviewed here