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.

Agile Retrospectives: Making Good Teams Great

Among the delegates was Jo Cranford of spikethepoodle.com (a little free advertising for you Jo) fame and I’m sure that she will have something to say about the session for those looking for a second opinion.

I always feel that meeting with a group like this who have varied experiences but common goals is productive in it’s self. This time was no exception, the group included a wide variety from those new to retrospectives to practising SCRUM masters and retrospective facilitators looking to freshen up there retrospectives.

I hadn’t picked up on this in the workshop title but Rachel was keen to concentrate on the specifics of sprint / iteration retrospectives and how this may differ from a project or longer term retrospective. In particular she considered the challenges of tight time scales. Given this pretext it was possible to provide a highly focused day with a healthy mix of slides and practical exercises. In particular Rachel expanded on the skills a facilitator must develop such as managing team dynamics and managing decision making.

The course benefited from a combination of theory, insights from a practitioner and roll-play. A taught part of this course was necessary and the generally accepted medium is projected slides. This seemed to frustrate all concerned, even Rachel commented negatively on the slide content. In my experience a white board is orders of magnitude more effective for teaching off. By contrast a big plus for me was the relaxed approach that included a group walk in the park after lunch. The roe pay after lunch provided an opportunity to try some of the techniques that had been discussed in the morning.

During the course Rachel made a number of recommendations:
Books

• Project Retrospectives – Norman Kerth: The book all those interested in retrospectives must read.
• Agile Retrospectives – Esther Derby & Diana Larsen: seems like a sequel to Kerths book concertrating on the shorter retrospectives recommended in many agile approaches

Logistics

• Sticky notes: A must in all shapes, colours & sizes. These are used through all sorts of exercises to allow a group to add ideas to any type of chart or timeline.
• Fidgets: These are whatever can keep the groups fidgeters busy during the retrospective. This could include some sort of talking token, mascot type cuddly toy or Rachel’s patented group of aliens that were ought over throughout the course.

Kerth’s prime directive:

“Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available and the situation at hand.”

This prime directive leads us to a phased approach to retrospectives.

1. Readying; here we create a feeling of safety. All participants must understand that this is not a witch hunt. We are all trying to improve the future, not blame for the past.
2. Reviewing; Kerth suggests approaches such as constructing time lines and relating emotions to project phases. In this way we can step back and see the context in which we were working.
3. Planning; this is about trying to affect the future. Approaches include “changing the wallpaper” to making suggestions to management.

The retrospective on retrospectives consisted primarily of lessons learnt, a few are listed below.

• Many organisations do not want to change
• Given some level of success, who will thank us for trying to go further?
• It is far to easy to feel like the retrospective is over after the meeting (nothing changes).
• Many people want to learn but breaking of habits is hard.
• Retrospectives that pull individuals from across functions can improve understanding.
• Retrospectives can be used in a variety of ways; project kick off, heartbeat, iteration, milestone.
• An outside facilitator can put people at ease and help avoid blame.

Finally Kerth suggested a couple of success stories. At Siemens the Austrian CEO successfully applied retrospectives to import “the Siemens way” into newly acquired companies. At Intel a senior manages studying the effects of retrospectives on productivity found that a 4 hour retrospective resulted in a 4 month productivity boost.