A discussion of Kanban can only go on for so long before the subject of the Theory of Constraints comes up. In this post I’ll try to explain just enough to show this connection.

Theory of Constraints (TOC) is a large subject that I was first introduced to some time ago by Pascal Van Cauwenberghe and his explanation of the 5 focusing steps for process improvement. Since then I’ve seen TOC pop up at a few Agile conferences. The most notable aspects that tend to be discussed are the 5 focusing steps mentioned earlier and the TOC thinking tools. The Thinking tools offer techniques for root cause analysis, problems solving, conflict resolution and planning. While there have been a number of books explaining these techniques the source material is a set of novels written by Eliyahu Goldratt the first being The Goal: A Process of Ongoing Improvement.

David’s first book (Agile Management for Software Engineering) was focused on applying TOC in a software engineering context so I guess it’s not surprising that he wold choose to spend a little time explaining the connection between Kanban and TOC.

At this stage I should say that where David has applied TOC he has subsequently realised that a Kanban approach would have led to an equivalent result and is a conceptually more simple approach.

The areas of TOC that David chose to focus on were the classification of bottlenecks and the application of Goldratt’s 5 focusing steps.

1. Identify the bottleneck
2. Decide how to exploit the bottleneck
3. Subordinate the system to the bottleneck
4. Elevate the bottleneck
5. Repeat

These steps carry with them a set of pre-suppositions.

• We understand the goal of the system
• A system has a single bottleneck that constrains it’s throughput
• It is better to undertake changes that have no cost first i.e. improve utilisation of existing resources before adding resources

While for most types of system I am willing to hold with these pre-suppositions we should accept that while bottlenecks can move in a manufacturing context they are likely to move more quickly within a software context due to the greater degree of variability.

So, an example of applying these steps in a software development context might be;

Our goal is to construct, test and deploy software.
Our constraint is in system test, this is apparent due to a build up of software that has not been tested.
We identify exploit opportunities by considering where we loose test capacity e.g. recording timesheets. Since test is the bottleneck, time spent doing administration is directly reducing the output of the system.
We subordinate the system to the bottleneck by changing responsibilities e.g. PM to take on some administrative tasks from testers.

At this stage we return to assessing where the bottleneck is. If we run out of exploit / subordinate opportunities we may choose to elevate the constraint. This is where we consider adding resources, automation or training.

To close we should consider how a bottleneck might manifest it’s self in a system. Though others have suggested classifications for bottlenecks David’s approach is to consider 2 types.
Capacity constrained resource
Non-instantly available resource

For example compare a bridge with a ferry. A bridge has a fixed capacity, congestion occurs where too many cars attempt to cross. A car ferry will cause queues even where capacity is sufficient due to it’s non-instant availability.

Technorati Tags: Kanban Coaching, Theory of Constraints

Given this it was interesting to reflect on why a Kanban approach might be right for a team or organisation looking to adopt an agile way of working.

David highlighted a number of reasons why Kanban might be the right approach including:

• Optimising an existing process is easier and more effective than trying to introduce a new one
• Provide what execs want
• Achieving high maturity

The first of these points challenges the approach that many process improvement initiatives have taken in providing new job titles, new process, new document templates and more. By contrast where an organisation has an existing process, possibly with specialisations and tooling in place, a Kanban initiative would seek to model existing workflows and expose issues leaving job titles and working methods intact. This approach is likely to meet less opposition since it cut’s less to what individual contributors care about and identify with. In addition a Kanban system should generate metrics that inform further improvements, for example to working practices. With luck, by this point sufficient buy in will have been achieved to minimise objections.

The second point cuts to one of David’s mantra’s. Exec’s, he asserts, all want the following:

1. Predictability
2. Business Agility
3. Good governance

In addition David likes to emphasise

• Empowerment without loss of control
• Self organisation without fear

Two aspects of David’s approach to applying Kanban appear to contribute a great deal to keeping these promises. The first is an emphasis on metrics. Particularly where an electronic tool is employed a Kanban system can inform a wide variety of management decisions. This is often missing where agile teams rely on a more emotional output from retrospectives. The second aspect is the exposing of policies. Many classes of issues that constrain the performance of development teams can be described as policies. Once de-personalised these can be considered with respect to the risk that they serve to mitigate and the benefit they bring as contrasted to the over-head.

And finally we come to the maturity argument. A high maturity organisation will be able to; make statistically defensible decisions, implement causal analysis and resolution and effectively deploy process improvements.

While a Kanban system will provide a rich set of metrics and enables the application of a great deal of knowledge accrued in the management of pull systems, it’s great strength (from my perspective) is process improvement. A Kanban system will make any mismatch in capacity between specialists visibile. The board can be annotated with information regarding blocking issues. But, best of all, where a blockage occurs the Kanban system will release resources to deal with the constraint.

Given this focus it seems likely that a Kanban approach may appeal to a class of organisation who see little appeal in more developer centric approaches. Kanban offers a tool set for the management of knowledge work. However, while Scrum and XP expose trust and respect as key principles these remain a choice for the manager applying Kanban.

Last month I was fortunate enough to attend David Anderson’s Kanban Coaching Workshop. Here is how David described it:

This 3 day workshop is for experienced Agile coaches, existing Kanban practitioners, and those who have previously taken David J. Anderson’s Kanban class. This workshop is intended to be an interactive collaborative session designed to facilitate knowledge sharing and learning. The class will be divided into approximately 10 sections with a slide presentation or tutorial from David to introduce each section. The goal is to enable participants to go back into the field and successfully coach Agile/Lean transitions using the Kanban approach. Each participant will received a personal recommendation from David J. Anderson as a result of participating in the class.

The three days were run in a very interactive style with 8 delegates including myself. Since all of the delegates were either Kanban practitioners or practicing agile coaches the discussion was both lively and in depth.

Subject matter covered a wide range including:

• Motivations for introducing Kanban
• Getting started with Kanban
• Comparing Agile and Lean decision making
• David’s “recipe for success”
• Reviewing David’s Microsoft XIT case study

Rachel Davies has already blogged some of her isights from the workshop here and I plan to add a few of my own key take-aways over the next few posts, these will be grouped under the Kanban Coaching tag.