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

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.

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?!

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.

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

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 should be handled normally. Intangible items apparently have no immediate cost of delay, though it is expected to rise at some more distant point in the future. Such items are useful background tasks to be handled when there are no more urgent tasks.

At a recent Kanban Masterclass I attended, David introduced an example to demonstrate the difference between Fixed Date Items and Standard Items:

A hotel/resort site wishes to offer two special promotions: one for the Spring/Easter holiday; one for Valentine's Day. Because people tend to book much later for Valentine's Day, the opportunity-cost of delay is likely to be much "steeper" - more like the Fixed Date case, compared to a more "Standard" shape for the other promotion.

This led to consideration of what the revenue projections for different release dates might be in these 2 cases, so I undertook to produce some sample data for discussion. Here they are.

The graph above shows the imagined additional sales generated by launching the Easter promotion on the dates shown. There's no point in launching before Christmas and New Year are over (zero cost of delay), so the first release date is January 1st. There's an initial bump when the first ads go out, then a growth in revenue, and in this case a rapid drop off when it is anticipated all places will be sold. Later releases follow a similar pattern but after 5 or 6 weeks' delay the cost in lost sales becomes much higher as sales go to the competition or simply have insufficient time to close.

The graph above plots the loss of revenue of the early February release (5 weeks delay) compared to 1st January release. Sales are always behind - even after the slight recovery in the period after the January release has sold-out.

Taking all the potential release dates and plotting the opportunity-cost for each delay produces the graph above - an S-curve showing little impact initially, rising more rapidly after the first couple of weeks.

Let's compare that with the simulated data for the Valentine's promotion.

In this case we are expecting nearly all the sales to be made in the last couple of weeks before the event. It really doesn't help to launch early because people won't book early any way!

So plotting the cost of delay in this case we get a curve which is much closer to the archetypal step function of the Fixed Date items. If there are items with higher opportunity cost of delay early on in the year, it is more beneficial to do these items, provided we don't miss the late January release for the Valentine's promotion, i.e. the point where the curve hits the "hockey stick" upwards.

Hopefully these examples help the understanding of the concept of using cost of delay for deciding which item an agile team should do next. Let us know if you have any real data examples to demonstrate this concept. I'd be most interested to hear about them.

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:

1. Start with what you do now
2. Agree to pursue incremental, evolutionary change
3. Respect 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 don't know. I just know the fourth one's arrived. Even Wikipedia (2013-04-16) knows it, so it must  be true! So here are the four:

1. Start with what you do now
2. Agree to pursue incremental, evolutionary change
3. Initially, respect current roles, responsibilities & job titles
4. Encourage acts of leadership at all levels from individual contributor to senior management

Yes number four's a good one. It should definitely be there. But do we really need four? Three is much easier to remember, quicker to share, and - when two of the principles say almost the same thing - three could be a potential improvement.

So here's my suggestion for when someone next updates the Principles of Kanban. That is, when they update the three foundational Principles of Kanban:

1. Start with what you do now (including the current roles, responsibilities & job titles)
2. Agree to pursue (incremental) evolutionary change
3. Encourage acts of leadership at all levels (from individual contributor to senior management)

If you want the snappy version, omit the phrases in parentheses.

See also "There are 6 core practices...".

Lessons in Agile Management by David J. Anderson

Holiday reading this year was David Anderson's "Road to Kanban" book. I had a similar initial reaction to this book as Malcolm Gladwell's "What the Dog Saw" - it's a compilation of previously published work (in this case from Anderson's blog) and if I didn't read it the first time why should I read it now?! In fact both books won me round very quickly. There's a lot of new work invested in "Lessons in Agile Management", in grouping related articles and commenting from a contemporary perspective on the developments in the agile community. There are also just valuable and insightful articles on many aspects of software development and management that I found both refreshing and original. Kanban is a relatively new kid on the block when it comes to agile frameworks - the major incumbent Scrum is consequently suspicious and negative towards it - but as this book shows, its roots are deep and arguably more secure than many views of agility. I would recommend this book to anyone wanting a broader understanding of the thinking behind Kanban and the principles it's built on. You will get a more balanced view than is possible from the texts that just focus on the methods artifacts and techniques.

Could Kanban be defined in a "Scale-free" manner?

Scale-free or scale-invariant processes are like fractals. They work independently of scale - from the intergalactic to the molecular if you like. Could a scale-free definition exist for an agile process such as Kanban - a process that would be robust and effective from the personal and small team scale to the scale of whole or multiple enterprises?

The Wiener process (random or Brownian variation) is scale-invariant (from Wikipedia)

I've recently returned from three days in Hamburg on +David Anderson's Kanban masterclass and this was one of the questions that was raised during the sessions. Uncontroversially Anderson stated that Kanban, like agile processes such as Scrum, XP and FDD, is not scale-free. Different definitions of Kanban exist at different scales. Personal Kanban applies to individuals and small teams. It uses a subset of the methods and techniques defined in Anderson's Blue Book and may have other techniques which are not applicable at higher levels. Equally Portfolio Kanban, which does not yet have a reference text, but exists in the experience of enterprises applying Kanban to multiple interconnected organisations and projects, is different enough to smaller-scale flavours of Kanban to be considered different in essence, not just in scale. 

I admit to finding this discussion frustrating since I think there is at least the possibility of defining Kanban in a scale-free manner. This would not be true of Scrum for example because the "immutable" roles, artifacts, events, and rules of Scrum are specific to the single-team scale. When you scale Scrum, even to a single scrum of scrums, the rules and practice have to be different at the larger scale. If we take the Blue Book definition of Kanban it maybe suffers from exactly the same problem. But the book is too large to be the process definition. Chapter 2 of the book might be a candidate, but it is not specific enough nor contains enough detail to test compliance.

I'm looking forward to the publication of a basic Kanban definition - Anderson stated it was in the pipeline - as my own feeling is that it should aim to be scale-free, at least over these three levels. Anderson positions Kanban as a process for organisation improvement in the knowledge work space. As such the practices relate to how to visualise work and improve, rather than the specifics of organising teams or indeed software development. At least at the first level of definition - the simplest and sparsest definition - keeping it scale-free should be both possible and useful.

Postscript: A possible candidate for a scale-free process is Feynman's Algorithm:

1. Write down the problem.
2. Think real hard.
3. Write down the solution.

One could argue this is a process only for a single person - I'm sure he intended it that way. But arguably it is scale-free. It's just the difficult and interesting part of the process as far as team problem solving is concerned (how do you write down the problem? how do you think together? how do you write down the solution) remains completely obscured. In the end it is only a trivial scale-free process.

Is there such a thing as a (non-trivial) scale-free agile process?

Kanban vs Scrum - less shootout more engagement needed!

David Anderson's book on Kanban provides a real insight into the practices and essentially the motivations for Kanban, particularly applied to process improvement. Since my reading happened to coincide with Ken Schwabers's dismissive posting about the method - saying that in contrast to the serious nature of Scrum it was a "nice distraction, for distracted people", it was helpful for me to look at all the examples, practices and theory in the book with as critical an eye as possible. I am a supporter of Scrum and believe it is the best starting point for team's starting out with a mandate to choose their process. However my recent clients have over 100 scrums working in parallel with a lot of other process surrounding them. They need methods for analyzing the waste in the processes and incrementally improving, based on sound metrics and evidence.

Kanban provides this kind of framework for improvement and I would strongly recommend such clients use it, as the basis for informed process development. As Henrik Kniberg points out in his companion volume to Anderson's, "Kanban and Scrum making the most of both", the methods are not incompatible. The fewer constraints that Kanban imposes on processes means that from a Scrum starting point, some of the constraints of scrum could be relaxed if benefit was deemed to flow from it. I presume this is why Schwaber objects to the method so strongly - if the starting point of the process is waterfall, one might end up with a slightly improved waterfall but not the major benefit that would flow from a true agile process. However if Kanban is followed effectively changes to a Scrum starting point would only be made if evidence was available for incremental improvements in the key business metrics. Yes there are risks involved in moving away from tried and tested agile processes. But that's where rewards lie too.

I'm not convinced by arguments between methods that focus on the character of those proposing them, when the substance of the methodologies are not examined. I expect more from the proponents in this case, more substance, evidence... and maybe a little more humility. Process improvement is not a one shot change from waterfall to agile. It requires insights from many different quarters to produce the best possible result for the business.

Theory of Constraints and Agile Project Management

Recently on the LinkedIn forum PM Toolbox, Arash Sadati asked for comments about tool support for how Goldratt's Theory of Constraints (TOC) or Critical Chain Project Management can be integrated as part of the Agile Project Management. Here are my thoughts on the subject.

One thing all agile projects share is that - because of a conscious removal of dependencies between features wherever possible - they will be resource constrained rather than critical path constrained (a generalisation but broadly valid). Methods like Scrum-XP try to avoid specific role constraints (e.g. we can't make progress because we don't have a BA or a GUI expert or a middleware expert available) by specifying only 3 role types (Product Owner, Scrum Master, Team Member). So the team as a whole must to some extent be generalists (or at least prepared to learn / fill in specific roles) to reduce the risk of role constraints. In any real application of Scrum of course such role constraints may be real and teams will have to pay attention to them. The default condition though is worth understanding because it's a means to keep the effect of role constraints to a minimum.

FDD defines many more roles and I think as a result there is a greater risk of role constraints. Availability of specific class owners for example is a typical problem which Palmer and Felsing discuss in their book on FDD. Flexibility, especially in small teams, for people to wear multiple role "hats" is crucial. The really interesting observation in comparing agile to waterfall is the requirements process where detailed specification of features is ideally "just in time". David Anderson and others point out that it is a serious waste of precious resources to allow too much work to be done on future requirements when the critical constraint is the development team.

When we were specifying the xProcess product which is designed to support any priority-driven process (any agile process in other words), we did want to be able to give visibility to problems arising from role or resource constraints. Patterns of tasks can be defined in custom processes that require specific or general roles - or even allocation to specific team members - so that forecasting can take into account not only the total development effort available, but in the cases where specialised roles are required. It can therefore show the impact of limited availability of critical roles. Custom reports can be generated to show resource utilisation, and where these show less than 100% utilisation, the situation is likely to be one where specific roles are "critical", requiring other roles to wait for them.

Requirements, requirements, requirements

Is it possible to implement an agile project without overhauling your requirements process? I think not. The key economic benefits flow from agile methods ability to reduce "work in progress" compared to traditional methods [Anderson]. This means specifiers must take a much lighter approach to distant requirements and have much greater involvement, for example as "on-site customers" or product owners, in requirements currently being implemented.

[Anderson] Agile Management, Prentice-Hall (2003)