Waterfall vs. Agile: A Retrospective

Image for Waterfall vs. Agile: A Retrospective

A few weeks ago, Intuitive Company partnered with the fine folks at Digital Project Management (DPM) Philly to host “The Agile versus Waterfall Debate, with a side of noodles.” We were excited to work with a great organization like DPM Philly, as well as collaborate with project managers and team members in our community. We chose to focus on the Agile and Waterfall methodologies because “Agile” is such a buzzword for project management these days, while Waterfall is often pushed aside. But is one really better than the other? We invited an expert team to explore the pros and cons of each in a debate format.

Moderated by our very own Jes Koepfler, the Waterfall debaters consisted of Rob Tannen (IC), Laura Richardson (Think Brownstone), and Natasha Baglin (AYC Media); the Agile debaters consisted of Emily Bryan (IC), David Wertheimer (WebLinc), and Emily Scala (Think Brownstone).

agile-waterfall-2

Here are some of the best points made by each team.

Pros of Waterfall:

Rob quickly gained everyone’s attention by putting on a poncho to prepare to talk about Waterfall and informing us that “ponchos are good for deflecting debris and bull****.” The Agile guns were a-blazin’ after that comment!

He argued that with the Waterfall approach, potential issues often found during development can be discovered and researched well before technical resources become heavily involved.

Natasha made a strong argument that better documentation comes out of the Waterfall process, with requirements-gathering and designing coming before valuable time and budget is wasted on coding. After all, most companies do not have a limitless budget and completely flexible deadlines.

Laura reminded us that Waterfall is a tried and tested method that has a small learning curve. At even a basic level, many people can relate to the step-by-step, organized process of working in a linear fashion. Many teams, and especially most of our clients, feel comfortable with this approach and like knowing what they’re going to get at the end.

agile-waterfall-3

Cons of Waterfall, generously provided by the Agile team:

Emily Scala and David reminded us that stakeholders and clients often do not know all of the requirements up front, so how can they give them to the project team? Even researchers and designers are not able to figure out all of the details and challenges that a developed prototype uncovers. With the Waterfall method, it’s difficult to accommodate the changing needs of the business, technology, or users. Key team members are idle for long periods of time, “waiting for their turn,” which makes resource allocation rigid and can create issues on other projects.

“There is no room for mistakes!” Emily Bryan added. Communication is limited to the beginning and the end of development. There is no consistent feedback loop from clients and/or stakeholders, which increases a project’s risk. Despite the team’s best efforts and perfect code, clients may still be unhappy after you’ve spent all that time and money on something.

 

Pros of Agile:

Emily Bryan led the debate by stating that change is inevitable. The one constant in life, and especially in digital project management, is change. Budget, timeline, technology constraints, business goals, promises from the sales team, third-party schedules and lots of other variables always seem to take twists and turns. The framework to weather this change is an Agile approach. Agile promotes discoverability, adaptability, accountability, and efficiency. “Unless change is something you’re really confident you won’t encounter, Agile’s the approach for you.”

David, backed by Emily Scala, spoke about the role of a project-manager-equivalent in scrum being a scrum master. This role is responsible for removing obstacles and keeping the team focused on the tasks at hand. The scrum master’s soft skills—such as impression management, people management, and servant leadership—help guide his or her team to produce high-velocity work. A key Agile principle is “communication over documentation.”

agile-waterfall-4

Cons of Agile, kindly provided by the Waterfall team:

Rob retorted to Emily’s list of Agile attributes. He claimed that an Agile project team is forced into being “adaptable” simply because requirements are not figured out ahead of time; the team is just playing catch-up throughout the project. He went on to say that business is “not a democracy” in terms of being accountable for your own work. If you don’t do your work, you should be called out for it by someone in charge and own up to it. The idea of efficiency in Agile is flawed, he reasoned, because work may be wrong and/or thrown away every two weeks.

Laura explained that Agile is still new to the marketplace and no one is doing Agile the same way, so collaboration becomes painful.

Natasha also raised some salient points regarding budgeting challenges. “I don’t know about you guys,” she said, “but I haven’t ever had a client tell me ‘I have an unlimited budget to figure things out as we go’.” One thing clients tend to have in common is a set budget and expectations of ROI. The Waterfall team cited healthcare.gov as a primary example of an Agile process failing. Due to the lack of early definition through research and ongoing testing, there were 834 million bugs, which sent the budget and user complaints skyrocketing. Careful planning with a Waterfall approach, on the other hand, allows budgets to be met and markets to be researched.

So who won?

You decide! No, really, YOU decide. Some of us in the audience referred to combined techniques from Waterfall and Agile (Watergile? Agilefall?) that we see happening in practice all the time. Observers from the event were able to take away some key points to use when project-planning with stakeholders and fellow team members.

Our moderator Jes summarized the debate nicely: “To properly execute our metaphor, we served DanDan Noodles from Han Dynasty, with a choice between forks and chop sticks! We pitted these two methods against each other for the sake of friendly debate, but really we see them as two tools in our ever-growing DPM toolbox. And at the end of the day, it’s all about using the right tool for the right job. Think about that bowl of DanDan Noodles as a client or project. Sometimes they’re slippery and sometimes you bite off more than you can chew. When you have more knowns and can plan accordingly, a fork might be the best tool to dive into those noodles and quickly fill your stomach. When things aren’t as clear and risk increases, it might be worth trying out a versatile set of chopsticks. They may be hard to use at first, but you’ll discover you can do all sorts of interesting things with them.”

agile-waterfall-5

About the Author

Image of Donamarie Schettino