« Is Assigning Roles the Best Way to get Agile Teams Started? | Main | Kanban Coaching Insights »

08 October 2009


TrackBack URL for this entry:

Listed below are links to weblogs that reference How to Create a Diagram of Effects:


Feed You can follow this conversation by subscribing to the comment feed for this post.

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/


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

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.


Post a comment

Comments are moderated, and will not appear until the author has approved them.

Your Information

(Name is required. Email address will not be displayed with the comment.)