Skip to main content


Showing posts from 2013

Postscript on Cycle Time

In my last post Visual explanation of Kanban terms I included a diagram and quotation from the Lean Lexicon (Chet Marchwinski et al Eds, 4th ed., Lean Enterprise Institute, 2008) which defines the meaning of Cycle time (CT1) as:
Cycle Time (CT): How often a part or product actually is completed by a process as timed by observation. In the interest of completeness, this postscript includes the definition of cycle time (CT2) from Factory Physics (Hopp, W.J and M. L. Spearman, 3rd ed., McGraw Hill, International Edition, 2008).
Cycle Time (CT): cycle time... is measured as the average time from when a job is released into a station or line to when it exits. (Where ambiguity is possible cycle time at station i is written CT(i).) The definitions are clear, concise, from authoritative and up to date sources and referencing authoritative primary sources. Unfortunately they are also contradictory. It is therefore unsurprising that the relatively new Kanban community finds it difficult to agree…

Visual explanation of Kanban terms

David Lowe has produced a very nice video to explain commonly used terms in Kanban in his blog post, Kanban Terminology. Here it is:

The post provides one set of definitions for Lead Time, Cycle Time, Throughput and Takt Time, using commonly applied definitions. The video is helpful and neatly done so I recommend it. However I do have some observations...

Now some of you may remember I said I was resigning as the self-appointed conscience of users of Kanban terminology. People can use whatever terms they like, provided they provide a brief explanation of which definition of a term they happen to be using. In which case, why on earth am I writing this blog to comment on David's excellent video?

(Should I stop now? Ah well, I've started now, so...)

The first point is that the confusion arising over definitions of the term Cycle Time is not a Kanban-specific issue. There are two distinct definitions of what Cycle Time is in the literature of manufacturing. To disambiguate the 2 d…

Shortest Possible Definition of Kanban... and why it matters for scaling

If you missed the Lean Kanban UK conference last week (you missed a treat!), there are two things you can do: Don't miss it next yearCatch up on some of the really excellent presentations, many of which are available on slide sharing sites These are my slides (above), but also check out those from Mike Burrows on "Kanban through its values", Håkan Forss on "The Red Brick Cancer", Pavel Brodzinski on "Fixing Portfolio Management, Dimitar Bakardzhiev on "Project Planning using Little’s Law", Troy Magennis on "Cycle Time Forecasting" and many others. The hashtag #lkuk13 is a good starting point for a search.
Really - don't miss next year!

Adapt - why success always begins with failure: Tim Harford

Why are you reading this book review?

Adapt came out in 2011 and it's a masterful summary of evolutionary development in economics, society, business and personal endeavour. It looks at the problems of finding solutions in complex spaces, safety measures in complex interconnected systems (like nuclear power stations, domino toppling, oil rigs and banking systems). Harford is erudite, amusing, insightful, anecdotal, informed and at times gripping. It's a great book.

Presumably you're reading this book review because you haven't read it.


You haven't read it?!

Stop reading this book review now! AND READ IT!

What's the quickest way to make a Gantt chart from an agile board?

Don't say it! I know. :-)

But someone actually asked this question this week, adding presumably to avoid embarrassment that the purpose was to "translate reality into management artifacts". He has a point of course. Familiar artifacts can allow people to see new things more clearly; we just also need to ensure that we've all understood what is really different in the new world.

Any way, I suggested looking at the Open Source tool xProcess, which uses its built-in forecasting engine to put start and end dates on a hierarchical collection of tasks or work items based on size estimates and team availability. I reckon if you have a table with task names you can generate such a chart in about 5 minutes.

Here are the instructions. Download xProcess from this site:

1. Create a project by hitting the "New" button like this:

You can choose various templates but just choose Simple Process / Simple Project. It's the.. well …

What is Kanban?

"What is Kanban?" you ask.

Well really that is three questions. Firstly what is a kanban?

1. A kanban is a visual signal.

It is a Japanese term meaning a card, brand or sign. In lean production systems it's used as the signal to an upstream part of the process that items are required by a downstream part of the process.

Which leads to the next question. What is a kanban system?

2. A kanban system is a system for managing work that uses (real or virtual) kanbans to control the flow.

Kanban systems were first used in Toyota for manufacturing but are now widely used in a wide variety of applications including health services and knowledge-based work such as software development. In principle a kanban system is a "pull-system" where work is triggered by demand from a downstream part of the process - ultimately by the demand of the consumer or commissioner of the product. The systems use kanban signals to prevent over or under production in various parts of the proc…

The mechanism of change in agile approaches

"Evolution" and "revolution" describe 2 mechanisms of change:
Revolution: sweep away and replaceEvolution: copy; differentiate; select; amplify; repeat This defines the difference between evolution and revolution - not the size of the change, or even the size of the steps in that change. It's the mechanism of change that is significant, because evolution (surprisingly to most people) can sometimes produce large changes in short periods, while revolution sometimes involves quite small changes.

Perhaps a discussion for another time is how this relates to politics and management, and why it is that many politicians/managers (even conservative ones) favour revolutionary changes - that they can take credit for? - over evolutionary changes, which necessarily require competition between ideas and failure of quite good ones, so that better ideas are amplified.

The mechanism of evolutionary change can be seen again and again in agile methods. I''ve written elsewh…

Improving Waterfall Processes (a thought experiment)

Some recent discussions about whether Kanban is an agile method or not seems to me to miss the point somewhat. The Kanban method is about improving your process, so whether you end up with an agile process depends on two things:
whether your process was agile to start withwhether "more effective" maps to "more agile" The first point started me thinking whether I could design a thought experiment by using Little's Law on that anathema of all non-agile processes - Waterfall! (Just say "no" I hear +Karl Scotland say. :-) More on that below, but let's deal with the second point first. 
Agility is the ability to change direction quickly in response to changing circumstances. A few businesses operate in very stable conditions and can optimise their processes to just these conditions. For them increasing throughput is usually the highest priority - agility may not be high on their priority list. However most of us working in knowledge-based disciplines fi…

Evolution and the culture of an adaptive organisation

One of the books that has most influenced my thinking about agile methods recently is The Origin of Wealth by Eric Beinhocker (Random House 2007, McKinsey & Company Inc. 2005). It's a book about economics rather than software products or development processes, so it's perhaps unsurprising it's less well known in agile circles than it ought to be. However it contains some key ideas vital to understanding the context of agile methods, specifically how products and processes evolve. Significantly it points the way for agile methods to focus on the evolution of process rather than simply the evolution of products - an insight Kanban has brought sharply into focus in recent times (not without controversy it has to be said!).

The mechanisms of evolution are the same whether the subject of evolution is a life form or the elements of an economy. These mechanisms - copy; differentiate; select; and amplify; repeated over many iterations - occur in all instances of evolution. Bei…

Why I don't use Cycle Time in Kanban

Why I don't use cycle time in Kanban from Andy Carmichael

These slides were produced in response to a request for a brief summary of the terms I use for describing flow systems, particularly in a Kanban context. Along the same theme also see The difference between Cycle Time and Lead TimeMore Musings on Little's LawVisual explanation of Kanban terms and In search of unambiguous terminology for Flow systems.

What is there to be afraid of?

What is worthy of our fear? Is Death? Surely not. He who lives will die, and such inevitability must be respected and known, yet not cause dread. No more fear taxes, since he who earns can scarce keep it all, can he, any more than he can take it with him? For what purpose would you keep it all? I grant you death and taxes should be avoided - where it's possible to do so with honesty and honour. But they are not worthy of our fear.

Maybe boredom is a more suitable object. To live an uninteresting life is both eminently possible and profoundly fearful. Don't you have a mind though, and doesn't it engender imagination? And is it beyond that imagination to find an action, project or enterprise that could engage you in some means of improving your own or your fellow's lot? Boredom is not worthy of fear, since it is easily remedied.

Yet I think there is an entity worthy of fear, fear true and cold. It is waste... the waste of human potential. Such waste inhabits every corner…

More Musings on Little's Law

My previous posting about why not  to use Cycle Time in Kanban resulted in some interesting discussions, and I'm grateful to +Steve Tendon for pointing me in the direction of this paper [1] by John D.C. Little and Stephen C. Graves which gives some very helpful historical background into the derivation of Little's Law, its applicability and some of the terminology used.

Little's own formulation of the "law" was as follows:



L = average number of items in the queuing system,
(equivalent to WIP in Kanban terminology)

W = average waiting time in the system for an item,
(equivalent to System Lead Time)

λ = average number of items arriving per unit time
(equivalent to Delivery Rate, assuming "stationarity")

With Kanban preferred terms we can see this maps to:

WIP =  Delivery Rate * Lead Time
Delivery Rate = WIP / Lead Time

Little used "waiting time" for the time taken by one unit to traverse the system (W) because his original context w…

The difference between Cycle Time and Lead Time... and why not to use Cycle Time in Kanban

Before addressing the question of which terms you should use in the Kanban method, let me attempt an explanation of the generally accepted meaning of these terms. (We'll come to the question of how generally later!)

Firstly Cycle Time: it is the time between units emerging from a process. You could visualise it like this:

Our system here could be a Development Team say, and the units User Stories (although we would expect to have more variation in this case). Equally it could be a bicycle assembly plant (working not very fast). The Cycle Time here is half a day because the system produces one unit every 0.5 days. Therefore the Delivery Rate (which is Kanban's preferred term for measuring throughput) is 2 units per day.

To understand Lead Time we need to put a marker on one of the items entering the process, and then see how long before that particular item emerges. Like this:

Lead Time is the time taken for one unit to pass through the process…

There are no flavours of Scrum

Here's a great posting from Jem D'jelal on the trials and tribulations of a London Scrum Master "Since When Did Ben & Jerry's Create Scrum?" I smiled throughout and recognised some of the frustrating situations that I also hit as a Scrum Master. However I realised Jem was also eloquently expounding some of my uneasiness with Scrum. Here's the stand-out section for me:

Whoever you are, please read and repeat the following mantra after me: There are no flavours of Scrum. There is no chocolate flavoured Scrum.There is no Caramel chew chew flavour of Scrum.Scrum is not an ice cream.It does not come in bloody flavours.If you want to pick an Agile framework, methodology, technique, or approach which comes in different flavours, go for one which is less prescriptive than Scrum. That is completely fine. Kanban for one example (There are only 2 principles, it leaves almost everything open. The only rules are you need to visualize your workflow and limit your WIP).Bu…

What is Scrumban?

What is "Scrumban"? The name seems to offer a simple answer - surely it's a mixture of Scrum and Kanban? So you think the rules of Scrum are a bit strict. You think Kanban doesn't offer enough guidance on things like roles and when planning and retrospectives should take place? Why not just mix the two and things are bound to be better!

The only snag with this is that Scrum and Kanban already have definitions which are not really compatible with this mixture idea. And Scrumban, at least in the original usage of the term, was coined with a different meaning than mixing the two methods (see Scrumban, Corey Ladas 2009).

The definition of what is and isn’t Scrum is well understood, thanks to the concise publication of its “rules” in the Scrum Guide. Scrum is a process framework – a set of guidelines and constraints within which your team can define and improve the process you use for developing products. It’s not a process as such - it is silent on many of the aspects a …

How to Adopt Kanban

Adopting Kanban does not require a massive change programme. Its effects however can be more far-reaching and long lasting than any expert-led transformation. How then do you adopt Kanban?

Here's my shortest-so-far adoption guide:
Change your viewpoint (lean flow paradigm):
See work as flowChange your mindset (foundational principles):
Start from here and improveChange your process continually (core practices):
Make work and policies visible; make validated improvements Sound simple? Maybe, but it's the starting point for a journey with no final destination - no process-nirvana of global optima. Improvement, like change, is here to stay.

Note: for tweeting purposes here's the even shorter version: see flow; start here; with visible work & policies, validate improvements.

See also: "What is Scrumban?"

The Starting Viewpoint of Kanban: The Lean Flow Paradigm

When you start using Kanban you need to change your viewpoint. Look at the world - in particular look at your work - through the prism of flow. It's amazing what you'll see.

Recently I've been looking for the shortest possible introduction for those starting Kanban. +David Anderson's foundational principles are a good candidate. Taking (I hope tolerable) liberties with the presentation of these, I summarise the principles as follows (please see "There are 3 ... Principles of Kanban" for what the "dot-dot-dots" stand for) :
Start with what you do now ...Agree to pursue ... evolutionary changeEncourage acts of leadership at all levels ... It's a great starting point.
But I'm dissatisfied with this, because applying the principles alone is not enough to ensure people are doing Kanban. Everyone is where they are, and many want to change in an evolutionary way, while encouraging acts of leadership. Most of them however are not doing Kanban!

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…