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