Waterfall versus agile decision tree
If you're working in a multi-modal organization you'll find this helpful: the canonical waterfall / agile decision tree.
I was recently asked to critique a new decision tree that helps teams decide between waterfall and agile when starting a new project. The intended outcome is to improve long-term results in the organization by giving teams the ability to make critical decisions quickly and accurately.
Overall, “good shift-left stuff” in my book. Anyhow, here’s the diagram I was asked to comment on:
I’m totally on board with making good decisions — and making sure there’s no ambiguity.
Putting my “decision tree flowchart” hat on, I can see a few confusing elements here:
Some lack of directionality can make the flow hard to read.
In a few cases, the ambiguity is enough that you could misread the diagram and land on the wrong decision.
Flowcharts may seem like a simple tool — and by and large they are — but making sure your directionality and decision points are unambiguous can get a bit tricky. Specifically, I can see more than one case that could result in a waterfall outcome where agile is the correct choice — and that would be a decision that has some long-term impact!
Fixing it was pretty straightforward. I think you’ll agree:1
No more ambiguity, and it’s just impossible to land on the wrong outcome.
If you’d like to learn more about decision trees and the canonical design language around them, I’d recommend ISO 5807:1985 as a solid source.2
I’ve written about How waterfall is wrong for software before; if you want to pick up on the actual science, start there.
ISO 5807:1985, Information processing — Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts. The international standard that codifies flowchart symbols and conventions. A readable overview lives in the Wikipedia article on flowcharts; the standard itself is at iso.org/standard/11955.