In July of this year I’ll be taking a class to become a certified ScrumMaster. It will be the first industry certification that I’ve earned in my career–I’ve frankly never found them to be valuable so I’ve avoided them. But as much as I’m passionate about building quality products, I’m even more passionate about the processes that enable building quality products. And besides, what’s cooler than a title that identifies me as Master.
The classical model of software development follows the Waterfall Model–that is, each process completes a set of deliverables and they “fall down” to the next tier. At least, that’s the theory. In practice it usually works more like a set of walls that each group throws their deliverables over as they’re completed–and the team who receives that deliverable is asked to follow that deliverable explicitly. The further “downstream” you are in the waterfall, the more frustrating this process becomes as you get further and further away from the true objective of the project.
Often we find that when we fill the requirements, we don’t really meet the objectives and happen upon a better way to meet the objective: this is called Emergence. While attempting to reduce uncertainty downstream (often quite unsuccessfully), the Waterfall also restricts our ability to act on the Emergent Properties we discover in a system as it is built. In my opinion, this restriction is the single largest cause of poor software design as it causes us to accept our requirements time leaps of faith over development time observations.
Emergent properties are very powerful tools to guide the way to great products and they should be embraced. Scrum and other Agile methodologies support these properties while the Waterfall, with all pun intended, drowns them.