Visualization: Why working iterative works
I’m really into visualizations. More often than not I can only really “get” something (a complex system, an abstract idea, a process etc.) when I see it visualized. You could call this the transformation of gut feelings into images.
So, I had this (rather obvious) gut feeling that working iterative in software projects makes a lot of sense, I’ve heard all the arguments and explanations and examples and stuff like that, and I probably already “got it”, but I thought it could make sense to clearly work out why exactly it makes sense, by visualizing it. Surely it’s no rocket surgery what happens here, but I kind of like it and would like to share it.
So here’s my approach:
The customer tells a product manager what he wants him to build. Let’s see how a waterfall approach leads to the product team failing at this:
The reason why what is finally delivered isn’t what the customer expected is that the project goes through the hands of different people and different stages, and every time the project is given to another person or team, the amount of misunderstanding grows. That’s only natural because we cannot copy ideas from one brain to another in a 1:1 manner.
Here is why an iterative approach makes sense:
The project really starts the same: There is a certain amount of misunderstanding, and the team does things wrong. But due to the regular feedback from the customer, this wrong direction can be corrected. It might then move into another direction which is still a bit wrong, but then comes the next correction, and finally everything is on track.