At Agile2010 I was chatting with George Dinwiddie about general process related stuff (probably with some reference to Kanban!) and I mentioned an idea I had submitted to a couple of conferences which had never got accepted. George suggested we try it as a Open Jam session, so we did!
The idea is to run a root cause analysis of various agile practices to drill down into why they work and what the benefits to be realised are. So rather than using a 5 whys approach to solve problems, it is used to understand solutions. For example, why do unit test? To minimise defects? Why do we want to minimise defects? To create less rework? Why do we want less rework? etc. The session tied in nicely with another Open Jam run by David Hussman on Dude’s Law, which also emphasised focusing on why rather than how.
Here are the outputs from the 3 practices we picked; Unit Testing, Iterations (Time Boxes) and Limiting WIP. Click to view the album with bigger pictures.
As a general exercise, I found it really useful and interesting. Definitely something to try submitting to future conferences again. The discussion and debate we had, and the surprising tangents we went on, was rewarding and enlightening. I was particularly fascinated by the comparison between Time Boxing and Limiting WIP and the way that creativity came out in both of them through different paths. I hope that by understanding why practice work in more detail, we can avoid following them dogmatically, and be in a better position to solve problems based on context. When a particular practice is not suitable we can draw on other practices which can provide the same benefits.
This is definitely something I want to explore further – hopefully with workshops at future conferences. If you try it out as well, blog your outputs and let me know!
Yes! The question of why (some) things work has been long overlooked, imo. Although it’s probably fair to say that it’s taken some years to understand that (many) specific practices actually DO work.
As well as “Why?” I would also ask the crucial question “and in what context?”
BTW Are those diagrams Current Reality Trees (TOC) or something else?
– Bob
Thanks Bob. The diagrams are just a made up format we came up with on the fly – nothing special!
[…] Dinwiddie has found some common ground between the two, Kanban focuses on limited WIP and suggests a short cycle time. Having regular cadences is […]
[…] Dinwiddie?????????????? […]
[…] Dinwiddie parece ter encontrado um ponto de equilíbrio, entre os argumentos sobre Scrum e Kanban: O Kanban tem foco em limitar o trabalho em progresso e […]
[…] approaches tend toward the same goals and use many similar techniques. Karl Scotland and I did some root cause analysis of practices a few years back and came to the conclusion that there were a lot of similarities between Kanban and Scrum [as the […]
[…] Dinwiddie parece ter encontrado um ponto de equilíbrio, entre os argumentos sobre Scrum e […]