Agile Versus Waterfall, Once and For All

As we race towards the date of my presentation at this October's Digital PM Summit, I'm working to crank out the remaining posts in my series that started after I first presented on the topic of growth at Drupalcon Austin. This seventh post touches on one of the biggest debates of the last decade in digital and software project management: Agile versus Waterfall. In my presentation I purport to "solve" the debate in two slides. This post will give a bit more context to those two slides!

Other Posts in This Series:

1. A Formula for Healthy Project Size Compared to Organization Size
2. Scaling Projects and Scaling the Organization
3. Unit Change During Project & Organizational Growth
4. Family-Sized Business Units & the Agency Holding Company Model
5. Beware the Matrix Model?
6. Communication Styles and Team Dynamics
7. Agile Versus Waterfall, Once and For All
8. Process Frameworks That Weather Growth
9. "Why" Not "What" Documentation
10. Project Manage the Organization
11. Plan or Pain?

A Principled Approach

First off, let's get a common misconception cleared up; Agile is a philosophy about software development, not a model for a process. Agile is a manifesto...

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

... and some principles...

- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximizing the amount of work not done—is essential
- Self-organizing teams
- Regular adaptation to changing circumstances

... that provide a cohesive perspective on how software should be developed. There are several popular models (including Scrum and Kanban) and a handful of other lesser-known options that attempt to embody Agile principles in a process, but those do not fully define Agile, and some stick to the manifesto better than others. In the opposite corner, Waterfall is a model for the process of software development. It brings with it no manifesto, no principles. That said, as a process Waterfall fails a number of the Agile principles (no surprise given that a goal of the Agile manifesto was to discredit Waterfall), so Waterfall implies in some cases the opposite principles.

Given this, you can compare Agile and Waterfall in one of two ways:

1. Debate the merits of the Agile principles that Waterfall is incompatible with
2. Compare the benefits and downsides of Waterfall and one of the methods that subscribes to Agile (most commonly Scrum)

The latter is almost always the debate I hear, so it's the debate I specifically want to address.

What's The Problem?

Software development breaks from decades of traditional wisdom around project management. Most industries (Construction, manufacturing, etc.) need processes that are very linear. Some phases of a linear project will happen concurrently, but by and large, one step follows another. The steps are all defined and have been done by a hundred other companies. Waterfall can be great for this type of work. On the other hand, software is often the anti-manufacturing. It's the act of learning. Of discovery. Of starting something without the end result being clearly defined. Of iterating until the problem gets solved. Given that, it makes sense to break down large problems into smaller problems so that the end result isn't either "we solved the problem" or "we couldn't figure it out" but instead wind up with "we were able to figure out about 90 of the 100 sub-problems making up the one big problem!" So common wisdom in software development is to avoid tacking a big problem and instead view the same project through the scope of lots of little problems tackled separately. Sounds pretty Agile, right?

It's All About (Un)certainty

When you approach the beginning of any project, a standard practice in defining what's to be done is to identify the problem(s) to be solved. Those problem statements will lead to user stories, tasks, specifications, and definition of all the other chunks of the project to be completed. Sometimes the stakeholders have an incredibly clear idea of the problems they're looking to solve, while other times they have only the vaguest notions of what they'd like to do. You might frame that as the stakeholder group's combined level of certainty about the project. Often certainty in web projects comes from answers to a number of questions:

1. Does the team have clear problems to solve?
2. Does the team think they know how to solve the problems?
3. Have they actually solved the problems before?
4. Has anyone else solved the problems before?
5. Can the team talk to those people?
6. Are the problems likely to change before the project solves them?

Answering these questions allows you to judge where the project falls on the spectrum we in the PM world like to refer to as the Cone of Uncertainty. The cone presents a really simple concept: as a project evolves, uncertainty decreases. If you look at the moment just before conception of a project in the original stakeholder's head, it is the purest form of certainty; the thought of it doesn't even exist yet to have any definition. The far opposite end of the project is completion, where everything is done, so there's nothing left to be certain about. Throughout the course of a project, uncertainty may vary slightly on a day-to-day basis, but the trend will always be towards decreasing uncertainty.

And now, what you've all been waiting for: the answer! Agile versus Waterfall decisions should be based entirely on the level of project uncertainty. If enough (or all) of the problems to be solved are known and unlikely to change before the project's completion date, then uncertainty-based risk is low, and Waterfall may just be the most efficient way to get to the finish line. If problems are vague and/or the goalposts are changing, then Agile is a no-brainer. The question for your organization to answer for itself in all of this is how much uncertainty risk you are comfortable bearing as a rule. While I advovate for determining process on a per-project basis, I think uncertainty risk threshold is something that should be defined organization-wide in general terms, so that those selecting the approach for a specific project can use the proper selection critera provided by organization leadership.

Metal Toad's Take on the Certainty/Uncertainty Threshhold

As we've grown, Agile (Scrum) has increasingly taken hold at Metal Toad. That's not just us buying into the Agile hype. It has been a natural progression based on our project size growing in parallel with our organization size. Three years ago, our projects were small enough that uncertainty was low; project durations were short, scopes were well-defined to the feature level before projects kicked off, and the number of stakeholders involved was small enough that decisions were clear and usually didn't change. Not surprisingly given those constraints, we often relied on something looking more like Waterfall to complete projects. Today's scenario is a bit different; we have 6+ month durations on many projects, and discoveries to get the team and external stakeholders on the same page are a way of life. Uncertainty is high, and that's great by us! We still do have some smaller projects that skirt the low/high certainty threshold, so for that reason we maintain a few core criteria that help us make the decision whether to lean Scrum or waterfall:

• 3+ Sprints: We usually stipulate that Scrum projects need to be, at a bare minimum, 3 sprints to be successful. Assuming two week sprints, that's a 6 week project. When we do Scrum, we only start to get a measurable sense of velocity after 3 sprints, so we're unable to effectively communicate to stakeholders how much work we'll deliver. Plus it takes too much time to spin up and then spin down a dedicated team on a short agile project. Which brings us to...
• Dedicated Core Team Members: Agile has only been successful for us when we can dedicate the core development team members to only that project. We'll do Scrum with only one full-time dev supported by PM, QA, strategy, etc. but prefer 2+ core developers when possible. Scrum (not surprisingly) starts to fall apart when developers are pulled in multiple directions by multiple projects.
• Minimum $: This one is simply extrapolated from the above stipulations of a) 3+ sprints and b) at least one dedicated dev with supporting roles. Given that times our hourly rate, we look to avoid Agile engagements for dollar values less than $60K. Not surprisingly, we generally look to avoid development engagements for less than $60K at this point!
• Client Product Owner Feasibility: The last (critically important) criteria that helps us determine the uncertainty around the project and whether Agile or Waterfall is the way forward is simply a gut check of how bought-in the client is on providing product ownership. We've atempted previously to own the product owner space on behalf of the client, but that's a tricky road to go down. Instead, we almost always look for an explicit 10+ hour/week commitment from a clearly identified product owner on the client side who is properly empowered to make decisions on the client's behalf. Even better is if they're already trained in Scrum or are easily trainable and open to the process of Scrum rather than liking a catchy buzzword. Many clients and developers alike think Scrum is some lightweight magic bullet for producting great development, but they're wrong! Done well, Scrum probably introduces MORE process and procedures, not less. Client time involvement is a huge part of Agile project success.

Catch me at the Digital PM Summit

Interested in the topic of organizational growth from a PM perspective? Join me and a bunch of fellow PMs at the 2014 Digital PM Summit in Austin this October! I'll be presenting a talk similar in nature to my Drupalcon presentation and related to this blog series, but new and improved after additional months of experience and iteration. The Bureau of Digital Affairs did a great job with the inaugural 2013 event, and 2014 promises even more in store. With a great lineup of speakers, topics, and of course after-parties, you'll definitely get your monies worth. I hope to see you there!