Don’t Go Chasing Waterfalls « Orange and Juicy

Don’t Go Chasing Waterfalls

June 20, 2011

Technology

Bob Cody

I’m going to start this blog post with a little ’90s music trivia… “Don’t go chasing waterfalls…” Little did TLC know back in the day that this lyrical hook would also ring true in software development? I’ve been doing this software development thing for a really long time and I have been washed down the river and over the software waterfall so many times I used to come to work wearing a wetsuit and a life jacket.

For years, we in the business of managing software development projects would start on this journey down river and over the falls. The classic Waterfall Methodology of software development was a very sequential process (analyze, design, implement, test, deploy) where once a step was completed, you did not go back. Oftentimes, we would finish a project only to find that we had missed the mark by some degree, that somehow the requirements changed, or the business needs changed and we did not know it. The only thing to do at that point is to take a very expensive trip back up river and start again. For the developer, this can mean updating/changing requirements or changing the design completely, which can produce a domino effect of additional changes throughout the system. For the customer, this means a longer schedule and potential budget overruns at a minimum.

For the past decade or so, a different method of software development has taken over the industry – Agile Software Development. Agile software development is actually a group of methodologies based on iterative development, a development process where smaller and shorter implementation cycles are repeated, each producing a completed piece of functionality. It is not that the steps aren’t followed; it is just that they are repeated many times throughout the life of the project, each time gaining important feedback from project stakeholders. Check out the Manifesto for Agile software development and the Principals behind the process.
With agile software development, requirements evolve over time through collaboration between the developers, business users and other project stakeholders. Progress is measured by delivering working software – more deliveries equal more progress. On an agile project, changes to requirements can be more readily responded to because users are seeing the product very early on in the software development lifecycle. Because the end user can see the parts of the completed product as they are implemented, it allows him to provide important feedback early in the development process where changes are easier to manage and become less expensive or have a negligible cost.

With Agile, what your team is NOT doing (wasting time implementing the wrong requirements) is just as important as what they ARE doing (collaborating to produce the best end product possible). Your customer doesn’t just perceive more value; you are delivering more value with each iteration because the development team is producing tangible parts of the end product in shorter, more frequent releases and not just at the end of the project.

So, “Don’t go chasing waterfalls”… it’s so ’90s.

Bob Cody

Director, Technology Consulting