Restore to Factory Settings: What to Do When a Change Programme Goes Wrong by Isabel Evans.
Isabel started her talk explaining what influence diagrams were about. And since the example found at Wikipedia is TLWR, she used a simple example.
She told us that when she gets sad, then she eats chocolate.
when she eats chocolate, then she gains weight.
When she gains weight, she gets sad.
And expressed this with a simple influence diagram.
Instead of using a mindmap where some items are related or belong to some others, in a influence diagram there is a circular relationship between all elements, creating a ecosystem of influences that helps us understand change, or why things got to a certain state.
Once this was clear, she moved on and explained how she started working for a big company with the mission of improve testing, and how she found out that it was not enough to improve testing, but that a lot of global improvements across the whole company had to take place in order to improve testing.
Check out her initial plan in green, and the influences she found out that were happening in red:
Also, she found out how the influence of management was impacting the developers, and came up with another nice diagram:
At the end of her talk, she linked her example to Joels law of leaky abstractions and how this law does not only apply to software, but also to process and relations inside the company.
What I got out of it:
I wasn't aware of influence diagrams as a powerful tool to explain circular cause-effect conditions, but since this talk, I think it's going to be a new tool in my belt.
At our peerTransfer office we have a nice influence diagram about development speed, just by the coffee machine.
You can find Isabel at Twitter, there is a nice interview at the Ministry of Testing and you can listen to her keynote at the EuroStar site.