Engineering is an old discipline.
“Pyramids” by David Bolton, licensed under CC-BY2.0. flickr.com/photos/davidbolton/4484379865
Very old.
Building with Atoms
The difference between building for digital and traditional modes of building is the difference between atoms and bits. For traditional engineers and designers who build with atoms, planning is often orders of magnitude less costly than building. Imagine what it takes to build a bridge or a stealth bomber. With these economics, it makes sense to plan first, and it’s crucial to get it right the first time. Only when planning is complete does it make sense to start building. These separate, distinct, serial phases are the heart of what agile software development calls “Waterfall”. Specialization is rewarded, so coordination among specialist groups (planners, builders, etc.) is crucial to minimizing idle time, so that hand-offs can occur in an orderly manner. In this world, predictability of timing and estimation is paramount.
Building with Bits
The digital world is different: the cost of planning and the cost of building is (roughly) the same—it’s certainly the same order-of-magnitude. Into this new world come new economies. Now that the cost of planning is as low as the cost of building, the imperative to Get It Right The First Time (Or Else!) disappears. Now, the important thing is getting it—something, anything—out into the world. Instead of having to model and predict whether you got it right, just get it out there and let the world tell you whether it’s good enough, and how to improve it. This is the fundamental change that makes agile software development possible, and leads to the great emphasis on experimentation, testing, and rapid iteration. In the old world we optimized for predictability. In this new world, we optimize to lower the cost-of-change.
How to build anything
So what does this mean? Agilists often disparage “waterfall” but it’s not as if traditional, Gantt-chart style planning is wrong or bad. (It’s responsible for the vast majority of planning and building—EVER.) Rather, Waterfall and Agile methods ought to be regarded as two different tools, optimal for different tasks.
Need to build in a domain where planning is much cheaper than building? Measure twice, cut once—waterfall is probably the right way to go. That doesn’t mean you can’t benefit from reducing the cost of change when possible, but it does mean that predictability ought to be prioritized over optimizing cost-of-change.
Building in a domain where planning and building cost about the same? Agile methodologies (which optimize for low cost of change) will give you a significant advantage.
jonathanpberger.com/blog 