Growing Kanban in Three Dimensions

Kanban systems can work at different scales and in widely different contexts. Indeed any organisation that delivers discrete packages of value ("work items") and which is interested in maximising the value and timeliness of its delivery, can analyse and improve its performance using the Kanban method. 

Kanban systems can grow - in fact in most cases it's much better that they grow than a massive process change is made suddenly across a whole organisation. "Big bangs" tend to be quite destructive, even if they could clear the way for something new. There are three dimensions in which Kanban systems grow:

• Width-wise growth: encompassing a wider scope of the lifecycle of work items than the typical "to do - doing - done" a single division of the process. It can cover from the idea to real value - or "concept to cash", though cash may come before or after the realisation of real value.
• Height-wise growth: by considering the hierarchy of items that make up valuable deliveries, each level of the hierarchy having differing flow characteristics. (This dimension use the "scale-free" nature of Kanban, the same principles and practices apply whatever the size of the work item.)
• Depth-wise growth: not only depth of understanding but depth of penetration through the full set of services required by the organisation to deliver value. (Sometimes referred to as "Scaling by not scaling" or "service-oriented Kanban", the approach here connects multiple services at the same level through feedback loops that balance the capacity of the various kanban systems.)

We'll look at each of these dimensions in upcoming articles. Which dimension to grow first will depend on context and the motivations for change. Any change needs to pay for itself with improvements in the flow of value, so asking "why?" is a more important first question than "what?".

When you come across a good idea ("agile" in general springs to mind at this point) it is very tempting to sweep away whatever you were doing before you were converted to the new idea, and start doing it everywhere. It should not come as a surprise to those who do this, that very soon a new idea will come along. With the poor results from mass conversion to the caricature of the original idea you adopted, the same cycle will be repeated. Instead grow the changes organically.

Try this: start small; understand the ideas as you assimilate them; grow what works and understand what doesn't work; work out why. Success will follow.

Acknowledgement: Thanks to +Pawel Brodzinski for the discussions on Portfolio Kanban... and one of the graphics on the top floor of the above diagram.

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!

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

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?