How to Create a Diagram of Effects

Here's a technique that we didn't have room to include in our Agile Coaching book---How to Create a Diagram of Effects.

Software projects have complex dynamics, there’s a lot going on and sometimes it's hard to see the forest for the trees. When coaching, you often want to encourage the team to see connections between the activities they spend their time on and the effects. What I like to do is create a Diagram of Effects with the team to explore the factors at play in a situation. These diagrams are from Systems Thinking which you can read more about in by Peter Senge's book "The Fifth Discipline" and also several books by Jerry Weinberg.

I was introduced to a technique for creating these diagrams by Marc Evers and Willem van den Ende at OT2003 conference. What I really like about their approach is that you can engage a group of people to create the diagram. You can also use it by yourself, for personal reflection about a situation you are currently facing.

All you need to get started is some sticky notes and markers. Now pick a problem to explore.

1. Start by brainstorming all the measurable factors in the situation. For
instance, # unit tests, # hours spent testing, # defects found, # hours spent fixing defects. Write each factor on a separate note.
 
2. Now lay out the notes on a whiteboard or a sheet of flipchart paper and look for relationships between the data. Review whether as one factor increases or decreases another factor changes? For example, # defects found has an effect on # hours spent fixing defects.

3. Move the notes that appear be related closer together so that connecting arrows can be drawn between them to showing the apparent influence effect. These arrows should show the direction of influence so the arrow between #defects found and #hours spent fixing defects points toward  #hours spent fixing defects. Tip: you can also draw arrows on sticky notes as it makes them easier to move around.
 
4. Consider whether the effect is a positive or negative effect. For example, as the # unit tests goes up the # hours spent testing might decrease, this is a negative effect. Draw a minus sign next to the arrow to show this. Annotate positive effects with plus signs.
 
5. The finished result should be a diagram that helps you see the big picture. Look for any reinforcing loops. Are there any interventions that you could make to change the effects?

I've included a sample diagram below.

This is a simple diagram of some effects that influence hours I spend at my computer. The reinforcing loops (marked with a snowball rolling downhill sign) show me some places that I could attempt to gain more balance in this system. For instance, I could switch to drinking decaf or herbal tea. However, there are many more factors that I could add to try and see the bigger picture. For example, if I didn't read emails I would miss out on business opportunities and that in turn could impact by ability to buy things, such as coffee!

Watch out when using these diagrams. People have a tendency to think that when there’s a relationship between two factors that it is a linear one and they can also be blind to effects that manifest after a time-delay. For instance, a common misconception is that adding developers to a project will bring the date in by an equal amount per person—this is often reinforced by planning software. Of course, this cannot be true, adding a couple of top-notch developers might improve the speed the team go at but adding a dozen mediocre developers is likely to slow the project down. Increasing team size impacts communication within team and time spent on learning how the system works needs to be factored in.

Finally, as Bas Vodde and Craig Larman remind us 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."

Comments

[Scott Duncan]

The way the final diagram looks reminds me of a system dynamics model and the use of "reinforcing" and "balancing" sounds like this. Any reason you didn't use the term "system dynamics" anywhere?

[Scott Duncan]

I should acknowledge that you mention Systems Thinking (and make theconnection to Senge and Weinberg). But the system dynamics literature is broader than those two folks. I will admit, though, that there is a certain technical hurdle to overcome in some system dynamics literature. The Senge and Weinberg materials are an appropriate start. Maybe you could just add a link to some system dynamics sources such as http://www.systemdynamics.org/, http://sdg.scripts.mit.edu/ or even http://en.wikipedia.org/wiki/System_dynamics?

[Rachel Davies]

These are very closely related/ I didn't mention it because I learned about the technique under the "systems thinking" label (named cloud).

Quoting from Wikipedia (http://en.wikipedia.org/wiki/System_dynamics)
"System dynamics is very similar to systems thinking and constructs the same causal loop diagrams of systems with feedback. However, system dynamics typically goes further and utilises simulation to study the behaviour of systems and the impact of alternative policies."

I'm sharing my tips on how to create these diagrams when working with teams. I'd do this to surface models and encourage problem solving in the context of coaching them to improve their process.

[Gerald M. Weinberg]

AS you point out, there are domains where S.D. is appropriate and others were Diagrams of Effects work better for me, at least. In the kind of team dynamic I write about, we seldom if ever can obtain the kind of data that allows us to compute a numerical effect. And the effort go obtain precise data tends to burden the use of the diagrams too heavily for anything useful to emerge from the effort.

OTOH, when accurate data are available, the S.D. approach can prove extremely useful--but I've never seen a situation involving agile development. But I haven't seen everything, not by a long shot. Best to know both approaches so you can pick the right tool for the right job.

[David Draper]

Thanks for sharing this approach, in terms of approach it is similar to the way I have been using cause and effect diagrams (TOC current reality trees).

I've blogged some more about this here - http://www.agiledesign.co.uk/retrospectives/cause-and-effect-in-retrospectives/

[JDM-GBG]

An analysis like this should (IMO) be done in conjunction with a five-whys exercise. If you focus only on the 'raw' brainstorming data to build up your diagram, you could end up treating one or more symptoms instead of the root problem(s).