Thanks to Rachel Davies for sharing her approach to constructing a diagram of effects.

Rachel proposes that the diagram of effects can trigger a team to discuss how a variety of issues relate and goes on to highlight advice from Bas Vodde and Craig Larman in their first book “Scaling Lean and Agile Development”, the First Law of Diagramming is “The primary value in diagrams is in the discussion while diagramming—we model to have a conversation.”

I have been using a slightly different approach in retrospectives recently. With a similar intent to Rachel I hope to trigger conversations that result in a team sharing there concerns and issues and coming to a shared view as to how these relate and where would be a good point for intervention.

I’ve used this approach a couple of times recently when running retrospectives that cover a few months i.e. not iteration retrospectives where we choose to commit a few hours to investigating issues in some detail.

My favoured approach is borrowed from Eliyahu Goldratt’s Theory of Constraints, it is one of the 5 TOC thinking process and is know as a current reality tree. A current reality tree is a tree of undesirable aspects of your current situation, these are connected to indicate cause and effect.

My approach to constructing this diagram is as follows:

Identify undesirable effects
Invite the whole team to stand around a table thinking of undesirable / unwanted traits of their existing approach (process, tools, methods etc.). Each item should be written on an index card and placed on the table in no particular order. Team members can try to avoid duplicats but if one pops up it is not a problem.

Begin to identify cause effect relationships
Invite the team to select two related cards. These should be stuck on the board and joining with an arrow pointing from cause to effect.

Continue to grow the diagram
The whole team should collaborate to add the cards to the diagram. When I first tried this I wondered how I would cope if groups of cards were not related. I’ve not seen this actually happen yet but should it then I guess we allow for the growth of separate diagrams until we discover a relationship.

Review relationships
In CRT literature there are a set of steps for assessing the existence and relationships between UDEs. My approach is to invite team members to consider where items are missing. Often where many causes relate to a single effect there is a missing intermediate effect.

Since I tend to run this approach in a time boxed session I an looking for the point at which returns begin to diminish. As the group settle on a basic shape and begin to look for intervention points I move to support this.

A good candidate point to intervene at would be contributing to a number of effects or participating in a feedback loop. By focusing on one effect we can select actions that will contribute to reducing this effect and by association those related effects.

Of course, an added benefit of this approach is that we can use the cause and effect diagram to review the effect of our interventions; did we get it right, if not was there something we missed in the analysis?

I hope that this is useful. Do share if you’ve used this approach or something similar yourself.

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