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

Scrumban - How to win friends and influence people?

My guess is that Ladas provokes extremes of like or dislike to his writing, depending on whether you happen to agree with him or not. Nevertheless I fall in the middle (well three and half stars rounded up perhaps!) as, while I do find the uncompromising ridicule of non-lean/less-lean processes somewhat wearing, I do think he's got some important ideas to share.

So I'm with the author on the main thrust of his argument, but just to dismiss eXtreme Programming for example as a reinterpretation of the V-model, seems less than just for one of the key advancing influences for agile in the first decade of this century. Similarly Scrum comes in for some merciless treatment - many people are going hate this book on an emotional level long before they parse the content - and especially if they interpreted the title as a description of an agile method that combines elements of Scrum and Kanban. That's not what Ladas means by Scrumban. He's discussing instead what evolution of process would take place if a team was using Scrum and adopted Kanban, while relaxing Scrum's rule-immutability. His answer is that many of Scrum's practices will change and you will end up with a much leaner process, with less work-in-progress, and independent cadences for queue replenishment, improvement events and releases. In other words you end up with a typical Kanban system. Hmmm... take care what you assume is in this book when you read the title!

Any way if you can get past his style, Ladas gives us some very interesting observations on Lean software development systems. In particular I found the "feature brigade" section fascinating - a discussion of how a Kanban process for software development could be built by analogy to a fire brigade's chain of buckets. The point about such a system is that it is self-levelling, since the point at which the fireman with an empty bucket meets the one with the full bucket is variable, depending on the current rate of working of the two participants. Such self-levelling of Kanban systems, if it can be achieved with simple feedback mechanisms like this, will lead to real advantages as they are scaled.

This is an idea worth persevering with the book for!