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

08 October 2009


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

The comments to this entry are closed.