Skip to main content


Showing posts from April, 2013

In search of unambiguous terminology for Flow systems

Confused by terms like cycle time, throughput, throughput time, lead time, value-adding time, utilisation, flow efficiency, resource efficiency and delivery rate? You are not alone!

One of the fundamentals of agile processes like Kanban and Scrum is that they are about the flow of work. Where older project management approaches have tended to focus on the single batch (the project), processes influenced by the Lean movement (and Toyota's production philosophy) emphasise the flow of work within a project, and of multiple projects. So agilists need to be able to understand, capture data about and improve flow.

One problem in getting good communication between the many experts, teams and sources in this area is common and unambiguous terminology. Just one example from 2 books on my desk at present... how do you express Little's Law (i.e. the law explaining the influence of work in progress on flow):
Throughput time = (flow units in process) * (cycle time) Delivery Rate = (work in p…

Scaling Kanban: Scale-Free or by "Not Scaling"

Nearly all agile processes started life as processes for single teams. Turns out this was very useful in getting software development processes that were appropriate to the domain (unlike single iteration waterfalls). It has brought a transformation in efficiency for small and - perhaps surprisingly - large projects alike. But
dealing with large projects always was the real problem. So the current interest in more formal definition of scaled agile processes is timely if not overdue.

I'm interested particularly in how Kanban scales. I think there are two separate threads to this:
Scale-free KanbanScaling Kanban by not scaling itScaling by not scaling is the idea - only touched upon in chapter 13 of +David Anderson's Blue Book - that multiple Kanban systems can be linked and balanced in an analogous manner to service-oriented architectures. The corporate operations review is the key feedback mechanism for the balancing process. Rather than expand on this idea here, it's maybe…

Selecting Backlog Items By Cost of Delay

Selecting the right items for an agile project to work on next is vital to ensure your team is delivering the maximum value possible to the business. Rather than "MoSCoW" (see recent post) or similar prioritisation schemes, +David Anderson's Kanban book recommends using the opportunity-cost of delay as the way to decide which items to pull next (or which items to put into the next sprint if you're using Scrum). He suggests 4 archetypes for categorising what the cost of delay might look like, when the impact (opportunity cost) is plotted against the time of release:

Expedite items have a high and immediate cost of delay. They should be started at once and given priority over other items. Fixed date items have a high cost of delay once a threshold is passed. They should be started before there is a significant risk this date will not be met. Standard items' cost of delay follows a fairly shallow S-curve, in other words, there is no reason to expedite them - they sho…

MoSCoW - is it a sensible way to prioritize requirements?

Back in the mists of time (some time in the last century) DSDM came up with a neat acronym for classifying the importance of requirements, MoSCoW - meaning a requirement was one of:
Must-HaveShould-HaveCould-HaveWon't Have (even if you Want it!) The problem with this scheme has always been getting stakeholders to specify their requirements as anything other than Must-Have and Project Managers to resource their projects so that there's anything other than barely enough time for the mandatory requirements. Just like my old boarding school - if it wasn't compulsory it was forbidden. Many agile practitioners have concluded that schemes like this which give user stories a priority value or category, are not worth the effort - just get the product owner to identify the next most important stories and we'll prioritize the other requirements later. I sympathise with that view but on a previous project I needed a way to introduce the idea of a "scope range" for each re…

"What's your favourite technique for estimating stories in Scrum?"

My number one favourite? Not estimating them at all! 

Instead, ensure stories do not exceed an agreed size that ensures they fit easily within a sprint (ok - I agree that's estimating, but it's much simpler estimating than tee-shirt sizes (S, M. L or/and too big) or points (1, 2, 3, 5, 8,  and too big). Then spend the time you've saved estimating the size of stories on estimating the number of stories in the various epics in your product backlog. Measure velocity in stories not points (or use only two sizes: 1 point and too big) and forecast the completion of epics and minimum-marketable-features based on the throughput of stories (velocity) and the number of stories. 

As well as saving a ton of time, it turns out your forecasting will be just as accurate as if you'd spent ages agonizing over each story! See for example +Vasco Duarte's blog about the evidence for improved forecasts from this approach.

The key question - as +Neil Killick points out in his recent "…

There are 6 general practices of Kanban... and I'm happy with that!

There are 6 general practices of Kanban, and in spite of my preference for groups of 3 (see "There are 3 ... Principles of Kanban"), I'm really happy with that. (I guess 7 would have a nice golden ring to it... but now I am being silly.)

The core practices are: VisualizeLimit Work-in-ProgressManage FlowMake Process Policies ExplicitImplement feedback mechanismsImprove Collaboratively, Evolve Experimentally (using models & the scientific method) Nevertheless I've found it useful to start a team off by emphasising three of these (no really): Visualize Limit Work-in-ProgressImprove Before we can manage the flow we need to see it, and so getting a Kanban board with items moving across it really is the first step. Limiting work in progress is the essence of Lean and fundamental to all agile processes. Surprisingly to most teams, it nearly always brings an immediate impact in increased throughput and reduced lead time. And finally, as the foundational principles tell us,…

There are 3, no make that 4... no really, shouldn't it be 3 Principles of Kanban?

+David Anderson first formulated the Foundational Principles of Kanban a few years ago:
Start with what you do nowAgree to pursue incremental, evolutionary changeRespect the current process, roles, responsibilities & titles I like that. It makes clear that Kanban is about changing your process (it isn't a process) and also that it's about changing your process in an evolutionary way - step by step, with a viable generation after each significant change. There's no known destination to the ideal, forever-great process, that we can produce a plan for getting to. Unlike the old farmer who replied to a request for directions with "You can't get there from here!", we have to get there from here, so let's start here.
I also like it because there's three! So much easier to remember.
But wait there's more. Recently the principles have been updated and there are now four. I'm sure someone will tell me when and by whom it was added, but I confess I d…

Better Daily Planning Meetings: Asking the Right Questions

+Joe Vallone provides a very useful insight into the right emphasis for daily stand-ups. In his blog Better Daily Planning Meetings: Asking the Right Questions he suggests slightly modifying the well-known standard questions (what did you do yesterday? ... etc.) to:
What did you get done yesterday?What will you get done today?What is preventing you from getting work done? This moves the emphasis from the activities to goals and helps a team focus on finishing work rather than simply doing it.
There's a similar purpose behind the standard Kanban practice of "walking the wall" from right to left, finding where tickets are stationary and seeking to unblock them. Flow only happens when things get done!