Grounding Waterfall and Agile in Reality

Imagining a world where the Waterfall and Agile software development methodologies commingle with ease can be difficult—the former is characterized by careful planning and discrete goals, while the latter is defined by flexibility and iterative targets. As such, when teams adopt a specific methodology, they often hit a wall, blame the methodology and move on. The truth of the matter, however, may be that they over-focused on the implementation of the methodology itself, rather than taking the pieces that worked, reshaping the methodology to fit the case and succeeding.

Waterfall vs. Agile

The Waterfall and Agile development methodologies are often viewed as opposite extremes and, increasingly, Agile is viewed as the answer to all the downfalls of Waterfall. Both, however, have their benefits and drawbacks.

Waterfall is a more traditional approach to software development that starts with doing all your planning up front. Every detail is ironed out from the very beginning and then executed according to the plan. As the name implies, every phase (requirements, functional specs, development, QA, etc.) occurs in a specific order following a detailed workflow. While this approach has its benefits—such as offering discrete business goals and deadlines—it can miss the mark because market conditions often shift over the duration of a project, leaving you with a product that doesn’t meet current needs.

Agile, meanwhile, is intentionally flexible. It addresses market shifts by working in small iterations called sprints that are broken up into small windows of time, typically two weeks. Within each sprint, the engineering team builds and tests before hitting mile markers. Each mile marker (success of a sprint) allows future priorities to change. By the time the product is close to market delivery, it should be able to meet current market demands. Agile isn’t without drawbacks, however. Since every sprint requires adjustments, it’s possible to find yourself continually working to adapt and never arriving at a worthwhile final product.

Never the Twain Shall Meet

While it may be difficult to see how Agile and Waterfall might complement each other, moving past seeing these two methodologies as mutually exclusive can work to amplify your organizational strengths while allowing for flexibility where needed. I’ll share a real-life story.

I once worked with a team that, with the best of intentions, adopted Agile in the form of pure, textbook Scrum (a popular application of Agile for software development). Everyone was indoctrinated in the ways of Scrum, work items were broken down into bite-size chunks, backlogs were rigorously groomed, burndown charts were visible on wall-mounted displays, and stand-ups were conducted daily where dialog outside the three questions (What’s done? What’s next? What’s blocked?) was strictly prohibited. After several sprints, however, the team became demoralized, and nothing meaningful was getting shipped.

The problem for us wasn’t Scrum. In fact, the team loved the concept, but putting it into practice in the strictest sense didn’t allow for unique aspects of the team or the product. The focus shifted to making burndown charts look good rather than delighting customers. Moreover, the rest of the business became frustrated by the team’s inability to make and hit delivery commitments, which eroded confidence and morale.

Getting Grounded

The key in grounding either approach is to adapt the method or methods that work best for your organization, project and team.

Instead of getting shiny ball syndrome with the methodologies themselves, think through the reality of your team’s situation first, and then pick and choose the aspects of each methodology that fit your needs. Here are some places to start:

1. Understanding objectives. Clarity of purpose around a business’s objectives informs how an organization should work; for example, delivering timely and predictable software each quarter or deploying to the cloud bi-weekly. Adopting a methodology that doesn’t align with the business can be counterproductive and lead to confusion.

2. Do what works. It’s OK to apply components of different methodologies to fashion something that works for a given team or project. For example, some advance planning may be necessary in the style of Waterfall for a large project so that a delivery timeframe can be estimated, after which the project is executed using an Agile approach.

3. Keep it simple. To avoid having your software development methodology hinder product delivery, keep concepts simple, such as clear roles and responsibilities for each member of the project team. Employ the right tools for planning, executing and tracking work while encouraging a positive team dynamic and accountability for delivering results.

4. People first. Emphasizing each individual’s skills and technical interests builds a collective sense of pride and ownership in the end result. Be wary of moving engineers between assignments based strictly on organizational capacity. Also, allowing individual work styles breathing room increases motivation, which serves your end results best.

5. Visibility into progress. A development methodology should offer transparency to the rest of the business. While the smaller details are less important, visibility into progress and achievement of milestones helps contribute to an atmosphere of trust and confidence.

You may determine that certain aspects of each methodology fit where others do not. Trying different methodologies will reveal which aspects are too rigid, too loose, or simply not a good fit for a particular project or team. Combining the best aspects of practices learned directly should help you find a development methodology suited to your organization, instead of simply a dogmatic ideal.