It is no secret that I am pro-Scrum. Scrum just seems to fit better with my personality. I enjoy working on a team that is agile, self-directed, and internally motivated. But that doesn’t mean that there aren’t times in which the waterfall methodology can’t be successfully used. In fact, I submit that there are some projects that would be better served by using waterfall rather than Scrum.

Based upon the Stacey Matrix, shown below, projects with very few unknowns and a high degree of agreement are considered simple projects. These types of projects would benefit from the waterfall method because they are usually too small and too simple to benefit from Scrum; they would probably not need a large enough team to have Scrum make sense.

Waterfall is sometimes derided in the Scrum community, and I don’t think it should be. In fact, I think Waterfall and Scrum suffer from the same ill; very few project teams actually follow all of the defined rules for either method. According to Dr. Winston Royce, the creator of the Waterfall methodology, a Waterfall project should: start with a huge amount of requirements gathering and documentation, include a requirements decision maker (product owner) on the team, and include enough time and budget to write the system twice. According to Dr. Royce, the first time through will always find issues that affect the core design, so it is imperative that enough time and budget is included in order to address these design defects.

How many Waterfall projects have you seen that have what Dr. Royce calls, “quite a lot” of documentation, “certainly more than most programmers, analysts, or program designers are willing to do if left to their own devices,” and has the major stakeholder on the team providing guidance, and includes enough time and budget to do the entire project twice? I haven’t worked on any. Most “Waterfall” projects I have worked on or heard about had limited budget for documentation, had barely enough time to do the project once, and had no access to the major stakeholders. Yet when a project fails, we like to blame the Waterfall methodology.

It works the same way with Scrum projects. I have worked on Scrumish projects that were called Scrum because they had time-boxed sprints, retrospective meetings, and something that was similar to a product backlog. But without access to the Product Owner, a Sprint Review with an acceptance process, and a Potentially Shippable Product Increment at the end, it isn’t Scrum.

When we do “Waterfall” in name, but don’t follow the Waterfall standard, we are doing something other than Waterfall, often “Waterfail.” When we are doing “Scrum” but ignoring key components that are needed to make it work, we are doing something other than Scrum.

To be clear, I don’t have a problem with trying new things. Neither Waterfall nor Scrum are perfect. A custom process could very well be the best solution for a given project. However, we should be intellectually honest when we deviate from the defined process and blame our changes, not the process that we mangled. I also submit that using the scientific method to test new ideas (gathering metrics before the change, making a single change, and then analyzing the metrics again) is a must.

So, which is better, Waterfall or Scrum? Neither. They both have their place in software development. While I believe the Stacey Matrix provides a good indicator for which to pick, I would rather see a project pick randomly and follow the defined process, than declare they are doing one or the other, and then completely ignore the core tenets of their choice.

See you next time…