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 on uniform and unambiguous terminology, since the Lean manufacturing community has already had this problem for a considerable time.

Lean Lexicon and Factory Physics - two clear, contemporary,authoritative... and unfortunately contradictory sources

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 definitions, I have taken to using the abbreviations CT1 and CT2.

CT1 is the average time between items emerging from a specific point in the process (for example the time between 1 item emerging from that point, say the Collection Window and the next item emerging). This definition is used in the Toyota Production System and is explained in these books and on-line references:

• Womack and Jones (1996, 2003) Lean Systems.
• Chet Marchwinski et al Eds, 4th ed (2008) Lean Lexicon, a graphical glossary for Lean Thinkers
• Mike Rother and John Shook (2003) Learning to See: Value Stream Mapping to Add Value and Eliminate MUDA 
• Jeffrey K. Liker (2004) The Toyota Way.
• Professor W. Bruce Chew's Harvard Business School Glossary of Terms (2004) [http://hbswk.hbs.edu/archive/1460.html] well explained in Fang Zhou's blog [http://www.isixsigma.com/methodology/lead-time-vs-cycle-time/]

CT2 on the other hand is the time taken by 1 item to pass between 2 points in a process, for example between the start and end points of the "Collection Process". This definition is used by these books and references:

• Hopp, W. J. and M. L. Spearman (2000). Factory Physics: Foundations of Manufacturing Management, 2nd (ed.), Irwin McGraw Hill, New York, NY.
• Donald G,  Reinertsen (2005) The Principles of Product Development Flow: Second Generation Lean Product Development

David Lowe's video uses the CT2 definition but, and here's another reason to be very cautious, unfortunately his example uses a situation where the WIP at each station (for example the "Collection Process") is one. Furthermore (check with Little's Law) when WIP = 1, CT1 = CT2! And this can result in people looking at the example and misinterpreting the definition.

Look at the Collection Process. The time between the start and end of the Collection Process in the video is 40 seconds. This is CT2, the definition for Cycle Time being used in the video. But if you were explaining this to someone who already knew about the CT1 definition, what would they think? The time between one item emerging and the next (CT1) is 40 seconds - no surprise there - so they carry on with their original assumption, and they would completely misinterpret the definition!

My recommendation for using an example to explain your definition of Cycle Time is to always ensure that the WIP does not equal one at any point, so this confusion does not arise. Say we said that the unit of work in this example, instead of being the order was the hamburger, and furthermore assumed that every car orders TWO hamburgers (WIP=2). In this case CT2 is exactly the same. Both hamburgers take 40 seconds from the start to the end of the process. However the average time between hamburgers emerging from this process, i.e. the average CT1, is 20 seconds! CT1 is not the same as CT2.

As David shows in the video, the time between items emerging from the final part of the process, or more accurately the time between items being demanded by customers (the target CT1) is known as Takt Time. Takt is a German word which can be loosely translated as... "Cycle" (aagghhh!). However it's a special cycle time - the target CT1 for the whole process, and thus also the target for each station. In this example, the griller of the patties should be finishing one hamburger every 20 seconds to avoid either under or over-production.

David and I were able to discuss this issue at the recent #lkuk13 conference (we sat together during Troy Magennis's Cycle Time Analytics keynote - yes I know "Cycle Time" again!).  Troy asked me during the presentation what I thought he should use instead of Cycle Time. I replied TIP, or Time In Process since I haven't yet found an ambiguous use of this term, of course realising that I can't change what people choose to use in their presentations - it's up to them. This confusion was pre-existing and no doubt will continue for a long time yet. I just want people to be aware of the nature of the ambiguity of this term. Removing the ambiguity can be quite hard since sometimes (as we've seen, when WIP=1) the two terms are equal, even though they are conceptually completely different.

Note the problem of defining Cycle Time in a context where WIP=1 appears to be common since very often in manufacturing a machine is processing only one part.

Postscript: Here's the diagram from the Lean Lexicon (referenced above) showing their definition of Cycle Time (CT1).

Cycle Time (CT1) From Lean Lexicon, a graphical glossary for Lean Thinkers

See also: Why I don't use Cycle Time in Kanban.

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:

1. Don't miss it next year
2. Catch 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.

WHAT?

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: http://sourceforge.net/projects/xprocess/

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

2. Add the list of work items by selecting "New" again and "Task". (See next screenshot).

3. Hit "Next" and you can add all the names from the cards on your wall as a comma separated list (see screenshot on the right). Leave the "Size" as 2 - we'll come back to that.

4. Now when you go to the Task List tab (or hit  the "Tasks" button) you should see something like the screenshot below. All your tasks are listed all of size 2.0 and with start and end forecast dates of NEVER.

In other word the Scheduler is forecasting none of these task will finish. That's because we have no resources assigned to the project. The simplest quick fix for this is to add yourself to the project. So...

5. Hit the "Resources" button and then "Add/New Resource", select yourself (or add team members) and then hit "Next". This gets to the "Appointment to Project" dialog shown below. You can define availability on this screen or just hit "Finish".

We now have enough information to generate a Gantt chart, albeit with some fairly big assumptions such as a uniform size of tasks and 100% availability of the team we've assigned. Nevertheless we can hit the "Gantt Chart" button and see the result.

Here's my attempt.

There are lots of things you may wish to adjust at this point like the priority order of the tasks, the estimates for the items (either the default value or individual ones) and team availability. You can even add separate subtasks for different parts of the process into a task template and add team roles so the right people are assigned to the right types of subtask. There are lots of adjustments you can make depending how much longer than 5 minutes you want to spend on this. You can even enter (or generate) fixed "target" dates which compare the forecast dates with dates that may have been agreed with a customer ( or are simply the forecast from last month). Endless hours of fun are possible. :-)

However if you just want to give your manager a comforting diagram, the steps above could be 5 minutes well spent!

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 process. The kanbans may be "real", for example an empty hopper which is sent back on the production line to indicate that more parts of a given type are needed, or "virtual", such as the signals derived from a kanban board when a "story card" is moved out of a column. In both cases they indicate to the upstream process that another item should be produced, processed or selected.

"But hang on! I thought Kanban was a method."

You're right. That's the third question, the third part of what is Kanban. To be crystal clear, we should ask "What is the Kanban Method?"

3. The Kanban Method is an approach to defining and improving kanban systems.

The Kanban Method emerged from work being done by many practitioners in software management, agile and lean methods and new product development  during the first decade of this century. The author of the method was David Anderson, but many others contributed or were doing similar work which fed into the method, including Drago Dumitriu, Jim Benson (co-author of Personal Kanban), Don Reinertsen (author of Flow), Karl Scotland, Corey Ladas (author of Scrumban), Alan Shalloway, Arne Rooke, Mattias Skarin... there are many more than I know about. Kanban was first formulated as a method in a paper presented by Anderson at the Agile 2007 conference in Washington DC, and in 2010 Anderson published what is still the principal authoritative text on the method, "Kanban: Successful evolutionary change for your technology business".

As Alistair Cockburn has observed the word "method" may confuse here - he suggests "reflective improvement framework" is closer to the intention (if it weren't such a mouthful I might agree with him!). I would say Kanban is a method, but a method for defining and improving a process, not the process itself or even a process framework. As such people are often confused by what they think are properties of the Kanban Method, whereas in fact they are simply characteristics of a particular kanban system that they have observed. Try not to be confused or you may miss the crucial value that Kanban can bring to your organisation - continuous evolutionary improvement. A method such as Scrumban for example is an application of the Kanban method to a process that starts off as Scrum or Scrum-like. Scrumban is Kanban, but in a particular context!

Elsewhere in this blog I discussed my shortest possible guide to adopting Kanban, based on the underlying paradigm, the principles and the practices of the Kanban Method. Here it is again:

1. Change your viewpoint (lean flow paradigm):
   See work as flow
2. Change your mindset (foundational principles):
   Start from here and improve
3. Change your process continually (core practices):
   Make work and policies visible; make validated improvements

The mechanism of change in agile approaches

"Evolution" and "revolution" describe 2 mechanisms of change:

1. Revolution: sweep away and replace
2. Evolution: 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 elsewhere about its relevance to the evolution of processes in Kanban (see "Evolution and the culture of an adaptive organisation"). Here's another example from a test driven process: the "test-change-test-change-test" cycle in BDD and TDD-like approaches.

A Test-Driven cycle in agile development

The point about this process is that it must start and end at "survivable" points, where specs, tests and model (i.e. code) agree. There are many cases where tests or metrics fail the quality test (a "red-bar" or failed build results) and these cases must either be changed again or reverted. There are also many points where change can be introduced: the model, the requirements or the tests of fitness, but every change is subject to the selection criteria which eliminates the unfit and amplifies (promotes to "head" - where it is again copied and modified) the instance with improvements.

This is not like evolution. It is evolution.

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:

1. whether your process was agile to start with
2. whether "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 find that the needs of our stakeholders change very rapidly. The ability to track this moving target and deliver new ideas faster is the key to being "more effective". For us agility does map to effectiveness.

So if we've decided being more agile is desirable in our context, how to go about it? Here are two possible approaches:

1. Look for a checklist of "agile practices" and adopt them (you may need a consultant who's cleverer than me to advise you on which ones must be adopted together and in which order!)
2. Look for a way to measure your "agility" then see if these measures improve as you make incremental changes to your current practices.

There is value in both approaches of course, since they are not mutually exclusive. However I know I am not alone in seeing failures in agile adoption initiatives where dependent practices are introduced in the wrong order (for example Scrum for team organisation, without automated build and test for regression testing). 

The second approach relies on having some measures of agility. Here are three from a recent David Anderson blog. They are cadences all measured in units of time:

1. how often can an organization interact with its customers to make selection and prioritization decisions about what to work on next? (queue replenishment period)
2. how quickly can the work be completed from making a commitment to do it? (lead time)
3. how often can new completed work be delivered and operational? (release period)

Now let's go back to whether your process was agile to start with. Let's take a fairly "waterfall" process, typical of many larger organisations, and let's see if focusing on just these metrics could provide significant improvements in agility. This thought experiment relies on Little's Law, which we can express as:

Lead Time =  WIP / Delivery Rate, where

Lead Time is the time a work item spends in the process (TIP or time in process is an alternative term)

Delivery Rate is the number of items delivered per unit of time (also called Throughput)

WIP is the number of work items are in the process at any point in time.

The initial waterfall(-ish) process

Our initial scenario is a product development company releasing a new version of a product roughly every 6 months, say 120 working days. It's not as extreme as some waterfall projects where no customer deliveries are made until years after the requirements are defined, but nor is it very agile. 

Let's say this project releases 24 new "Features" (independently releasable functionality) which are selected at the start of the analysis phase for each 6-monthly release. Each Feature can be further broken down to around  10 User Stories. (Or whatever the waterfall equivalent is! Development tasks say.) There are 3 stages in our (very simplified) process: Analysis, Development, and Release. Testing is included in the Development phase (something they must have learned from a passing agile team!).

• Analysis of an Feature takes a Business Analyst an average of 20 working days. The team has 4 Analysts so 24 Features will take 120 working days to specify.
• Development of a User Story takes 2 developers (possibly a Programmer and a Tester) 5 elapsed days to complete. With a team of 20 developers, this phase will take around 120 working days to complete the 240 stories.
• Release typically takes 10 days elapsed regardless of these size of the release. We assume however that development and analysis work may continue in parallel with this phase.

A View of the Features in Process

How do the 3 agility metrics look with this process?

• queue replenishment period: this is around 120 working days. When a release comes out and the development team start on the next release, the analysts start on the release after that, so its 120 days between each of these requirement selection meetings.
• lead time: from selection of the 24 Features, through their analysis (120), development (120) and release (10), the wait is 250 working days
• release cadence: this is the 120 working days between releases

The average Delivery Rate for this process is 0.2 Features per working day.

Let's compare this with the ideal continuous process assuming the same productivity as above but releasing as frequently as possible. Now such a change cannot be made immediately - it's a major mistake to increase the frequency of releases without improving automated build and test for example. It's more important to select smaller incremental steps where the risk of breaking the system is lower but effectiveness (including agility) can be shown to improve. But for the purpose of our thought experiment let's jump forward, assuming the basic numbers are the same, but we've reached a stage where the process can run continuously. Let's also assume the 4 analysts working together could deliver one Feature spec in 5 days rather than the 20 taken by one lone analyst.

WIP Limits for the New Process

A new Feature will be started on average every 5 working days. Dividing our 20 developers into 4 teams will allow each team to deliver separate Features, averaging 20 development days per Feature. The average arrival rate of completed Features will be 1 every 5 days. Unless we can reduce the 10 days required for each release, we would have to release 2 Features at a time, but even so our agility metrics will show massive improvement.

• queue replenishment cadence: as a new Feature is started every 5 days, we can select Features one at a time every 5 days (down from 120). If the business selected 2 at a time the period would be 10 days.
• lead time: from selection of each Features, through its analysis (5), development (20) and release (10) the wait is 35 working days (down from 250!)
• release cadence: this is now down to 10 working days between releases (down from 120). This is the minimum without addressing the release process itself - an obvious place to look for further improvement.

The average Delivery Rate is still 0.2 Features per working day (this is inherent in our assumptions above). 

The conclusion from this experiment? Agility can be measured and it can be improved radically by changing batch processes into continuous ones (or making batches as small as possible). Agile practices are needed to enable effectiveness and improved productivity at low batch sizes, but the pay-off is seen in the reduction in the times between queue replenishments and releases... and most especially in the reduction in lead time.

Footnote on Little's Law calculations:

The improvements in the 3 agile cadences in this thought experiment are based simply on adding up the times suggested by our scenario. We can derive these results using Little's Law instead, which is easier if the numbers don't drop out quite so easily as our simple scenario. First let's re-run the scenarios above.

Here's the initial waterfall process:

Average Delivery Rate = 0.2 Features per day
Average WIP = 24 Features in Analysis + 24 Features in Development + (24 in Release) * 10 days / 120 days
Thus Average WIP = 50 Features

This results in an Average Lead Time = 50 / 0.2 = 250 days

Here's the more continuous process:

Average Delivery Rate = 0.2 Features per day (still)
Average WIP = 1 Feature in Analysis + 4 Features in Development + 2 in Release
Thus Average WIP = 7 Features

This results in an Average Lead Time = 7 / 0.2 = 35 days

What would be the impact if we could reduce the 10 days of the release process down to 1 day (maybe by introducing techniques from Continuous Delivery). What would the new Lead Time be? Is it just 9 days less? Let's see.

With a 1 day release process, we can deliver Features one by one with a release on average every 2.5 days. So the figures become:

Average Delivery Rate = 0.2 Features per day (still our assumption)
Average WIP = 1 Feature in Analysis + 4 Features in Development + (1 in Release) * 1 day / 2.5 days
Thus Average WIP = 5.4 Features

This results in an Average Lead Time = 5.4 / 0.2 = 27 days

The reduction of 8 rather than 9 days is not easy to derive intuitively, proving the worth of Little's Law to continue the thought experiment and gauge the impact of improvements to other aspects of the process.

Why not try a few scenarios yourself?

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. Beinhocker demonstrates that the process by which "Physical Technology" and "Social Technology" have developed in the history of human economic activity is evolution. It's not just like evolution, it actually is evolution, with similar characteristics advantages and drawbacks that arise from it.

Furthermore its success is absolutely remarkable in both the scope of economic growth and its accelerating speed. Physical Technology refers to the artifacts of human activity from pottery and stone axes to razor blades, mobile phones, insurance policies and car washes - "product" is perhaps a simpler term. Social Technology refers to the means by which humans organise themselves and the mechanisms they use to produce the products of the economy - again I prefer a simpler term, "process". Products and processes have been evolving in an accelerating manner over millennia. At this point in history it is essential to economic survival, not only to understand these mechanisms, but also to actively participate in them. As others have said: "change - like survival - is optional!"

One of the most relevant sections of what is after all a fairly dense 600+ pages, occurs at the end of the book. Beinhocker turns his attention to how businesses need to behave within the very rapid cycle of innovation that now characterises the economy. Evolution is taking place outside organisations whatever organisations do. Whether it happens within an organisation however, and thereby enables the products and processes of the organisation to evolve sufficiently to survive and thrive in the new context, depends on the culture of the organisation - whether it is an "adaptive organisation". Rigid hierarchical organisations can survive if their context (market) is either controlled by the organisation itself or changing only very slowly. When enough change occurs to allow new organisations to compete, such rigid organisations disappear. In fast moving markets only "fit" organisations can survive in the long term.

Here is Beinhocker's summary of the characteristics of adaptive organisations that can survive in today's markets:

• Performance norms
• Performance orientation – people go the extra mile, continuous improvement expected
• Honesty – people are honest, transparent and face reality
• Meritocracy – rewards are set on the basis of merit
• Cooperating norms
• Mutual trust – trusting and trustworthy
• Reciprocity – the golden rule
• Shared purpose – common goals above personal
• Innovating norms
• Non-hierarchical – quality of the idea over status of proposer
• Openness – curious, outside thinking, experiment, seek the best
• Fact-based – facts rather than opinions ultimately count
• Challenge – competitive urgency, race with no finish line

These are the characteristics that allow evolution to occur within an organisation - not just by its death and replacement. Are you struck, as I was, how closely this mirrors the goals and norms of agile teams?

It is no coincidence that agile values match those of adaptive organisations. Agile methods recognise evolution as the key mechanism at work in improving products and improving processes. Kanban as defined in +David Anderson's Blue Book explicitly calls out evolution as the mechanism of change in its principles. Furthermore it has made the key leap beyond earlier agile methods that proposed a static Social Technology to implement evolving Physical Technologies (i.e. the use of a pre-defined process). Kanban applies evolution to the Social Technology itself. Kanban in that sense is a meta-process, a means to keep organisations in Beinhocker's "fit" state by evolving the processes it uses. In my view this makes it important for all agile teams to understand, whatever label they apply to their own current process.

The way you yourself change is at least as important as the way you change the things you are producing.

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 Time, More Musings on Little's Law, Visual 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 of life where ideas spring up and are swallowed, spontaneously springing to life and dying like fundamental particles separating and colliding undetectably in the depths of space. Waste of human potential is omnipresent. It occurs in places of learning, and places of work, in families and in churches, in friendships and in war. It steals not only from those whose potential is untapped but from their communities, their

 relationships and indeed all society.


Fear this waste. Yes. Fear it and fight it.

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.

From Little and Graves (2008)

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

L=λW

where

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
or
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 was queuing systems. For other applications he suggested Flow Time, which I think is a very useful alternative.

He also notes though that other authors use other terms for W, including cycle time, throughput time, and sojourn time, depending on the context. Yes - cycle time I'm afraid is in that list which is why confusion still abounds. This conflicts with the more generally accepted definition of cycle time in manufacturing, which corresponds to the target rate of working expressed as Takt Time, and is the reciprocal of Delivery Rate. In other words this confusion of terminology is at least as old as the reference Little and Graves cite: Factory Physics by Hopp and Spearman (1st edition:1996).

Useful background, but the message to me is still: "Don't use Cycle Time in Kanban!".


References:

[1] Little, J. D. C and S. C. Graves (2008). Little's Law, pp 81-100, in D. Chhajed and TJ. Lowe (eds.) Building Intuition: Insights From Basic Operations Management Models and Principles. doi: 10.1007/978-0-387 -73699-0, (c) Springer Science + Business Media, LLC http://web.mit.edu/sgraves/www/papers/Little%27s%20Law-Published.pdf

[2] Hopp, W. J. and M. L. Spearman (2000). Factory Physics: Foundations of Manufacturing Management, 2nd (ed.), Irwin McGraw Hill, New York, NY.

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. So our Lead Time here is 5 days.

Now before we consider Little's Law, can you look at those 2 pictures and tell me how many units of work there are in progress in the system under study (WIP)?

Scroll down when you've thought about it...






Scrolling...






Still Scrolling...






Nearly there...




Anyone say 10? That wasn't too hard was it? You've just derived a simple application of Little's Law for a regular (and "stationary") process, and you probably found it easier than plugging the numbers into Little's Law itself:

Delivery Rate = WIP / Lead Time

or

WIP = Delivery Rate * Lead Time
WIP = 2 * 5 = 10

So Cycle Time (as defined here) and Lead Time are very different concepts. However there is one important case where they are equal... when there is only one unit in progress in our system (plug WIP=1 into the formula if you doubt this, or change the Lead Time in the example above to 0.5 days and visualise what is happening). Whenever WIP>1, Lead Time will be longer than Cycle Time.

Why not use Cycle Time in Kanban?

Ok so if that's what the terms mean, why shouldn't we use Cycle Time in a Kanban context?

Put simply, because people use different terms to mean the same thing, and - even worse - the same term to mean different things. And the worst confusion is associated with the terms Cycle Time and Lead Time.

There are authoritative sources from well-respected authors that use Cycle Time to mean something different to its common usage in manufacturing circles (the meaning explained above). This inevitably leads to a whole bunch of confusion. This is why a session at the recent "Kanban Leadership Retreat" (#klrat) led by +Dan Brown sought a common policy for use of these terms in Kanban. They proposed a first step which was that the terms recommended by Kanban for use in Little's Law should be Delivery Rate, Lead Time and Work In Progress (WIP). Furthermore it proposed that the use of Cycle Time should be deprecated, and its reciprocal Delivery Rate should be used instead.

I happen to agree and support this proposal, but I also think there is a necessary second step: to understand what Cycle Time is, as defined in manufacturing, so that you can explain why we use Delivery Rate in Kanban instead of this term as the measure of throughput, and also so that you can explain the Kanban terminology to those who wish to use Cycle Time and Lead Time as synonyms... and hopefully persuade them to adopt the agreed Kanban terms instead.

Good luck!

See also: Why I don't use cycle time in Kanban and Glossary Proposal

Notes:

See also: the  list of terms and definitions that you need when measuring flow and efficiency in Kanban, posted previously.

I'm indebted to this Harvard Business School archive from the year 2000 (which uses Professor W. Bruce Chew's glossary) for the clearest explanation of these terms I've seen so far [http://hbswk.hbs.edu/archive/1460.html], also for the discussion of cycle time In Womack and Jones' "Lean Thinking" (1996, 2003),  and for this blog [http://www.isixsigma.com/methodology/lead-time-vs-cycle-time/] from Fang Zhou which also gives a very clear explanation and was my source for the HBS page .

I'm also very grateful to all those from the Kanban community who have put up with my badgering  and whining about this issue over the last few weeks! Their comments have helped me clarify the issue and decide how best I can explain it to my clients.

In accepting Lead Time as the preferred term for the time taken by one unit passing through the system, the Kanban community has to acknowledge some problems, particularly that some people wish to use this term only for the time from customer order to delivery (which is why qualifying this term, e.g. System Lead Time, may be needed). Little himself used "Wait Time" (because his context was queuing systems). However he also suggested the term Flow Time, which is certainly another good candidate for an unambiguous term.

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

But Scrum does have rules... if you do not follow these 9 rules then you are not doing a different ‘flavour’ of Scrum – you are simply NOT doing Scrum.

But doesn't this make you uneasy Jem? Don’t you worry (like me) that as agilists we want to embrace change while at the same time saying these particular practices are eternal? Many changes from a good method like Scrum are bad (measured say by a reduction in the flow of value in this context). But does that imply every conceivable change, even from a process that is working exceptionally well, will always be bad?

And where does the idea come from that Kanban has two principles (see my post "There are 3, no make that 4... no really, shouldn't it be 3 Principles of Kanban?"). The two rules (i.e. practices that if you are not doing, you are definitely not doing Kanban) come from Jim Benson's Personal Kanban book which is just the starting point of exploring this method. Don't be fooled this sums up the whole approach. (These "rules" are the first two of the six practices of Kanban.)

Since none of the principles of Kanban (whether there are 2, 3 or 4) mention WIP or visualisation shouldn't we take a look at the principle that is relevant here, and the one that makes me comfortable to be a Scrum Master using Scrum with all its rules intact (except the one about the rules being immutable).

The principle is “agree to pursue evolutionary change”. This implies you’ll try some changes that don’t work and don’t get amplified. But also if some changes work, you’ll amplify them even if they break the previous policy you were applying.

We use this in the Retrospective (which incidentally we still do every Sprint) to encourage each other to find small changes - for example to the Definition of Done (DoD) - that might improve the situation we're in. For instance if there are too many bugs coming back at us from the Release process or the field, we ask whether a tighter DoD might help. If the change works we keep it and tell other people about it (select, amplify). If we can't tell whether it's better, we'll probably keep it (diversity in the ecosystem). If it makes things worse we regress (deselect). In other words we're using an evolutionary change mechanism.

Our Scrum team limits work in progress by not putting too much into the Sprint Backlog and by focusing on finishing stories we've started rather than starting new ones. And we visualise most of our work using a Scrum board and burndown charts. Why should anyone tell me I am not using both Scrum and Kanban just because there's one Scrum rule that I refuse to accept in my context... that the rules are immutable?

Now our use of Kanban is not very deep at this point and there are several practices where we're certainly deficient. (Not following all the Kanban practices doesn't mean we are not doing Kanban by the way, which is a key difference from Scrum). Take Kanban practice number 3:"Manage Flow". We've begun to gather metrics on elapsed time for stories from entering In Progress to Done (Development Lead Time), but we haven't gone wider yet in the value flow, nor used this to ensure smoother and more flow-efficient ways all the way from "bright idea" to released, which is our ambition. There should be some good improvements we can get here in the future.

I admit after some period of time of changing our process, you may tell me Jem that I'm not even using a flavour of Scrum, it's just not Scrum. Probably at that point I won't mind too much (unless of course you were to interview me and not give me a job as a result!).

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 process needs (it says you need a “Definition of Done” for example, but not what it should be). However it is a framework that is very specific about some aspects of the process, such as when planning meetings take place and how long they should last.

Scrum is often contrasted with Kanban, also a framework, but more accurately described as an improvement framework; that is the approach for assessing and improving your process. Kanban has fewer constraints or rules than Scrum, allowing a wide range of processes from those based on Scrum itself to many variants – agile and less agile – which can be the process's starting point . As +David Anderson explains, "A Kanban system is overlaid on an existing process." Provided you can look at your work as a flow of items - usually this is simply a case of changing the way you look at your work - you can use Kanban to assess and improve your process.

As yet there is not the simple definition booklet that defines what is and is not Kanban, so the best starting point is the “Blue Book”, Kanban (Anderson, 2007), plus the summaries - published informally since that time - of the foundational principles and core practices. Because I like short definitions, I've summarised these as "how to adopt Kanban":

1. See work as flow (Lean Flow Paradigm)
2. Start from here and improve (Foundational Principles)
3. Make work and policies explicit;
   Make validated improvements (Core Practices)

If you are doing this, you are doing Kanban, even if your policy for work in progress (usually cited as a key difference between Scrum and Kanban), is to limit work in a Sprint to that which the team believes it can complete (the policy that Scrum applies)... or if you decide not to limit work in progress at all.

In fact there is nothing in Scrum that is incompatible with adopting Kanban as well. Nothing that is except the “rule” that the rules can’t change. If you can validate that it would be an improvement to do planning more or less frequently, or to decouple the frenquency at which you do retrospectives from the frequency at which you do reviews, Kanban would say you should make that change. Scrum might say okay make the change too, but if you do so you are no longer doing Scrum.

So this is the key to what Scrumban is. Scrumban is a process being improved using Kanban, which probably is no longer strictly Scrum. Some part of the strict Scrum framework has been modified (or maybe was never tried) because it is believed the change is more appropriate, brings more benefits or incurs less cost than pure Scrum. Such processes used to be referred to, somewhat derogatorily as “Scrumbut”. Scrumban is the more acceptable, less pejorative alternative... and it's also more positive because it implies you're using Kanban.

In his book on Scrumban, Corey Ladas describes a possible trajectory for a process that starts off as Scrum and changes as Kanban improvements are applied. This is what he meant by “Scrumban”. At the end of the story the process has very little similarity to Scrum and few people would even describe it as “Scrumban”. It is simply a flow-based process, as near as possible to single piece flow, with a typical Kanban improvement process around it. Is this process still Scrumban? At the point when the similarities to Scrum have disappeared, I’d suggest the label is not helpful. Many have concluded the label itself is not helpful anywhere since it causes the kind of confusion that is visible in statements like "I prefer Scumban to Kanban" or "Kanban is a better process than Scrum". Look at the definition of these terms and it’s clear such statements are not really meaningful.

I think though that a commonly accepted definition of Scrumban would be useful, at least to reduce the confusion in discussions around this topic. So here’s my attempt:

“Scrumban is a Scrum or Scrum-like process which is being improved with Kanban.”

This definition implies that if you are doing Scrumban you are using Kanban! Maybe that will be difficult to accept for some people, particularly if they believe their approach is "better than Kanban". Maybe a Scrumban community will emerge and wish to define distinctive practices from Kanban, just as most Scrumban processes differ from Scrum in some (albeit different) ways. In the meantime I’ll continue to use the term Scrumban - guilty secret: yes I do use the word! And when I do, that’s what I mean by it.

Postscript:
You can't do Kanban in a vacuum. You need a starting point. If your starting process is based on Scrum or is Scrum-like, then according to this definition it is Scrumban. If the starting point was Prince II or XP or DSDM should you call it Princeban, XPban or DSDMban?!

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:

1. Change your viewpoint (lean flow paradigm):
   See work as flow
2. Change your mindset (foundational principles):
   Start from here and improve
3. Change 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) :

1. Start with what you do now ...
2. Agree to pursue ... evolutionary change
3. Encourage 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!

See the flow! One way to visualise work in progress

Simple you say - just adopt the principles and start doing the Kanban core practices (see "There are 6 core practices of Kanban"). But this is also unsatisfactory. The practices are not all followed by those who are doing Kanban. Not everyone uses a visual board (or other visualisation) yet. Not everyone has WIP limits yet. Not everyone has explicit policies yet. Unlike Scrum which says that if you are not doing all of Scrum you are not doing Scrum, Kanban describes itself as a way to improve from whatever you are doing now. As +David Anderson makes clear, even such "proto-kanban" implementations bring benefit, and these partial or shallow implementations of Kanban do fall under the banner of Kanban.

So how can we express the missing element to the foundational principles? I think the answer is to explain the starting viewpoint. Before applying the foundational principles of Kanban, and before you've started doing its core practices, change your viewpoint...

The Starting Viewpoint: Look at your work as Flow.

Notice this viewpoint statement isn't asking you to do anything yet, except look. Just look in a different way and you'll be amazed what you see. Seeing work as flow - items moving from an initial concept through one or more other stages to "done" may not seem that profound. Yet it opens up a completely different way to analyse and manage work. Furthermore as a starting point it means you can look back on work recently done and collect data relating to the flow, even before any aspect of the process has been changed. You can ask:

1. How long did this item take from concept to delivery?
2. How many items were completed in the period?
3. How many items are currently being worked on?
4. How long is the time between deliveries?

The answers to such questions are likely to highlight the issues the business cares about or is dissatisfied with. From there finding the insight to make improvements is a natural process. As I found recently with a team I am working with, there's usually data about the flow of work available from the recent or even distant past. Looking at that data again through the viewpoint of flow will show you what you can improve and importantly, whether you have improved once you have made changes.

I'm grateful to +Rodrigo Yoshima whose abstract for Lean Kanban North America 2013 on Management and Change used the phrase "Lean Flow Paradigm". It was the trigger for this post. His slide-share for the presentation is available here, and it's well worth a look for examples of how seeing work as flow helps teams and management to improve things.

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):

1. Throughput time = (flow units in process) * (cycle time) 
2. Delivery Rate = (work in progress) / (lead time)

When you realise that some sources use cycle time and lead time interchangeably, meaning the time taken from one point of the process (usually the "start") to another (usually the "end"), you can see this is a big mess. Both equations are correct provided you understand the definition of the terms.

So here's my goal: I'd like to start using terms that, even if they are not universally used, they do not get used by authoritative sources to mean something completely different!

Immediately that means cycle time is out, because for some (those using equation 1 for example) it means the time between the completion of units (the reciprocal of throughput or delivery rate), and for others it means the time between points in the process.

Lead Time (rather than Throughput Time, another alternative) is the generally preferred term for the time between points in the process in the Kanban community, but this can also be problematic since the natural language use of this term refers to the time between placing an order (as a customer) and receiving the goods. This may include parts of the process which,the designer of a Kanban system has no control over (e.g. agent web sites, queues before entering the system, third party delivery systems, and so on).

We could redefine Lead Time to mean just the time in our system (which suffers from the "other authoritative sources" problem), or - better in my opinion - qualify the term whenever we use it in a formal context: for example System Lead Time; QA Lead Time; Development Lead Time. This means the term is unambiguous (provided the prefixes have been defined for the system) and it also means we can slice the system temporally to view the Little Law effects within subsets of the process.

Term 1 - Lead Time: the time taken for a unit of work to move from one point in the process to another. Used informally to mean either System Lead Time (i.e. the time for a unit to move from the start to end of the system under consideration) or Customer Lead Time (i.e. the time from customer order to customer delivery). Otherwise the term should be qualified to determine the start and end point of the measurement. (Measured in: days, hours, seconds, etc.)

Term 2 - Work In Progress: the number of units of work currently within a specified part of the system or the whole system. Prefer this term to flow units in process or similar.(Measured in: "units".)

Which term should be used for the rate at which units pass through the system or part of the system? Velocity (in Scrum), Delivery Rate and Throughput are all used frequently - probably Delivery Rate is more common in the Kanban community, though I have a slight preference for Throughput. It is only one word, and it applies equally to a subset of the system as to the final delivery part. [Post-publishing Note: The Kanban Leadership Retreat, June 2013 confirmed Delivery Rate as the preferred term.] So...

Term 3 - Delivery Rate: the rate at which units of work pass through the system or part of the system. As with Lead  Time the term may be qualified with a phrase that determines context - e.g. System Delivery Rate or Development Delivery Rate. (Measured in: "units" per day/hour/second.)

So we can now translate the two versions of Little's Law above to preferred terms:

1. System Lead Time = (Work In Progress) / (System Delivery Rate)
2. System Delivery Rate= (Work In Progress) / (System Lead Time)

("System" could be omitted in these equations if the context is clear.)

Finally let's define value-adding time and the 2 efficiency terms for good measure. I'm indebted to Modig and Åhlström's excellent "This is Lean" for these definitions.

Term 4 - Value-adding Time: the total time spent on value-adding activities for one unit of work. Value-adding activities exclude waiting and superfluous work .

Term 5 - Resource Efficiency: a measure of the utilisation of a given resource, i.e. the ratio between the time working on adding value in the system to the total time available.

Term 6 - Flow Efficiency: a measure of time-utilisation on a given unit of work, i.e. the ratio of the Value-adding Time to the (System) Lead Time.

Lean approaches emphasise Flow Efficiency over Resource Efficiency, since maximising Resource Efficiency, so often the first concern of accountants and managers, eventually leads to the traffic-jam state of no flow (see graph above). The efficiency paradox is that the most effective use of resources is achieved at a point where both Resource Efficiency and Flow Efficiency are less than one.

See also: What's the difference between Cycle Time and Lead Time... and why to just use Lead Time in Kanban.

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:

1. Scale-free Kanban
2. Scaling Kanban by not scaling it

Scaling 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 the topic for another post. Suffice to say it's the potentially "self-balancing" nature of such joined systems that make it such a powerful idea.

Scale-free Kanban on the other hand uses the fact that the definition of Kanban does not specifically reference the size of the items flowing, or the size of the context in which they are flowing. Hence Kanban can apply at different levels (see separate blog post "Could Kanban be defined in a "Scale-free" manner?"). At least three scales of Kanban are already in use:

1. Portfolio Kanban
2. Blue Book Kanban
3. Personal Kanban

The standard or "reference" scale corresponds to the method as described in the Blue Book. It concerns a small to medium size project (1-4 teams perhaps), with items flowing through each stage of the process between 0.5 and 5 days. (I'm not trying to be precise btw!)

Small scale would correspond to Benson and Barry's Personal Kanban. A single worker, pair or small team working on tasks that usually take a day or less.

Large scale concerns the flow of projects, releases or major features - it has been labelled Portfolio Kanban by some, including Pawel Brodzinski who has brought a new focus on this area.

At least at these 3 scales the principles and practices of Kanban can apply without modification. Some may  require less stress (for example the reference to levels of the organisation is not particularly relevant at the small scale), but all are applicable.

What is even more striking is that we already know how to link these different levels - several Kanban tools even use this property of Kanban to support boards at different scales out of the box. 

The flow-items are different at each scale. Portfolio flow-items may be projects, releases or major features (an interesting separate discussion: what do/should businesses track at the portfolio level?). We might refer to these items for example as "funded work packages". The business level Kanban board has a collection of these moving from the proposal stage, through approval and development to released. The (dynamic) decomposition of such items into minimum-marketable-features, epics, stories, etc. eventually leads to the items that will flow across the project/team level boards. At this level the items are often referred to as stories, features, defects or backlog items. Blockers at this level can reflect upwards, as can forecasting based on flow/throughput, and eventually completion. Precisely the same kind of levelling can apply, if desired, to take project flow items (stories say) down to personal tasks tracked on a personal Kanban board.

An important aspect to note here is that concurrent use of these three levels depends on the flow-items at one level decomposing into smaller flow-items at the next level down. This is why this hierarchical approach is an alternative to the balanced service-oriented model of the not-scaling approach, where the flow-items are "related peers" (for example a blocker in one system spawns a backlog item in another).

While it's good news that these scales can be unified in principle, practices may already be diverging across the 3 levels - for example it seems to be popular practice in Portfolio Boards to reverse the direction of flow so that items that will be delivered later are shown to the right of the board rather than on the left (see Pawel Brodzinski's example here). However I believe it is still worth preserving the commonality of method definition and to embrace Kanban's consistency over multiple scales moving forward..