3 Reasons To Transition From Waterfall to Agile

At the Big Software Company where I used to work, my 60 colleagues and I built our entire project every night, and nobody was allowed to check in broken code. At any moment there was a complete functional application that passed all regression tests. It was my first Agile, as beautiful as synchronized swimming.

And you can’t do synchronized swimming in a Waterfall.

Yet the lure of Waterfall remains strong,even in organizations that have made the switch intellectually. Because at its core is a promise: Everything’s going to work out exactly like we planned. A lot of organizations would find it easier to make the transition to Agile if they got this kind of assurance. But the reason Waterfall has failed is that it can’t deliver on the promise.

Agile can. And as the East Coast  Director of Consulting Services at MarkLogic I am often in the privileged  position of introducing Agile to our leading customers. I’ve  seen the good the bad and the utterly resistant and I have  3 key reasons why organizations like McGraw Hill, Dow Jones, and Condé Nast have chosen Agile over Waterfall.

1. Risk Stays Flat

In Waterfall, the risk curve rises every day. Business can’t realize profit or market advantage until the project is completely developed and tested. If the market rejects the project, Business has to crank the whole machine back up: new requirements, a Gantt chart, test plans, more budget. Let’s form a new development team because the original team is disbanded. Let’s reinvent this thing. A whole new risk curve is born. The cost of the project increases, and there is no way of putting any value back in to offset the expense.

In Agile, however, the risk curve stays flat. The model of short sprints allows for constant tuning of the design. Continuous integration assures always-functional software that can be productized. An Agile User Acceptance Test, synchronized with development sprints, gives Business the feedback it needs to be responsive.

2. Good Enough Beats Tyranny of Perfection

Finishing work to a “good-enough” level means that the cost of the work will not exceed the business value of what’s produced. In my consulting engagements, I work with a lot of smart, driven people. Can we shave a few milliseconds off this operation? Can we prune a few more lines of code from that algorithm? We can always envision a better form, a cleaner syntax. But good-enough software is powerfully pragmatic. Often my team helps to build RESTful services. Inevitably, we come to a point where, yeah, you could use a strict resource-based API, but maybe functional-style calls will get you there faster. Pass the parameters and don’t forget the hot sauce.

3. Business Stays In The Loop

In Waterfall, software development is hard. The geeks who are nuts enough to devote their careers to it have a secret vocabulary and spend a lot of time typing furiously or staring fixedly at their screens. Their activities are unfathomable and the issues they wrestle with are esoteric. They can only commune with other geeks.  So, while technology is being built, business owners feel shut out, and unable to control the very projects their own careers depend on.

In Agile, software development is still hard, and it’s still done by people with unique skills and outlooks. To mitigate the culture clash between Business and Technology, Agile creates many points of contact between the two groups. In Waterfall, Business may feel it has more power to dictate a plan and hold Technology accountable. In fact, the linear, hand-off-y style of Waterfall allows Business and Technology to grow further and further apart, so two-thirds of the way through, Business is saying, “I have no idea what’s taking them so long,” and Technology is saying, “They never knew what they wanted in the first place.” In Agile, Technology has to surface at the end of every sprint and show Business what it’s doing. Business can then dial the cost and speed of the project at a very fine resolution. It’s like when you’re moving clips around in Garageband and you turn on snap to grid. Wow, now my guitar solo starts on the beat.

If you are forming an Agile team like the ones at MarkLogic’s leading customers, you may find these points helpful in winning over folks who don’t know what Agile is, or why you’d want to use it. Happy Developing!