Waterfall vs. Agile – a knowledge problem, not a requirements problem

Even though the Project Management Institute (PMI) began accepting applications for their Certified Practitioner program over a year ago now, many experienced, veteran project managers still disregard agile methods and stress the importance of Waterfall approaches. Their rationale is simple:

Premise: Many projects fail because they have poor planning, analysis and design

The literature over the last decade clearly shows the reasons for project failure.

68% of IT projects primary cause of failure is poor requirements (IAG, 2009):

  • Companies with poor business analysis capability will have three times as many project failures as successes.
  • 68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. In fact, 50% of this groups projects were runaway which had any 2 of: taking over 180% of target time to deliver; consuming in excess of 160% of estimated budget; or delivering under 70% of the target required functionality.
  • Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects.
  • Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization.
  • The vast majority of projects surveyed did not utilize sufficient business analysis skill to consistently bring projects in on time and budget. The level of competency required is higher than that employed within projects for 70% of the companies surveyed.

From Forrester:

  • Poorly defined applications (miscommunication between business and IT) contribute to a 66% project failure rate, costing U.S. businesses at least $30 billion every year

Meta Group:

  • 60% – 80% of project failures can be attributed directly to poor requirements gathering, analysis, and management


  • 50% are rolled back out of production (Gartner)
  • 40% of problems are found by end users (Gartner)

Carnegie Mellon

  • 25% – 40% of all spending on projects is wasted as a result of re-work

Dynamic Markets Limited, 2007:

  • Up to 80% of budgets are consumed fixing self-inflicted problems

Conclusion: Projects require more up-front design to ‘get it right’ and ‘lock-down requirements’ before more money is spent in developing a software application or product

Joel Spolsky, a commentator on software development, has argued strongly in favor of Big Design Up Front:

“Many times, thinking things out in advance saved us serious development headaches later on. … [on making a particular specification change] … Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule. I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that.”

The verdict?

Good planning, analysis and design are critical to project success, as is communication and a shared vision of what is being delivered. The fallacy is assuming that this effort must be entirely done up-front, in totality, by specialists and then handed down to developers in the form of documentation for them to interpret.

It’s a myth that the average analyst can be assigned any project. The evidence here: an average analyst will fail to achieve process re-engineering objectives over 60% of the time. Average analysts do not deal well with process change objectives. Their requirements discovery process appears to be fundamentally different than that used by elite analysts.

Excellence comes through a rethinking of how requirements are done.

– IAG Consulting, 2009

Requirements & knowledge transfer

Waterfall’s design-up-front approach requires specialists to undertake tasks to clarify requirements, document them, and then hand them over to those who will implement them.

Knowledge Type Description Scrum Waterfall
Tacit knowledge Deeply personal experience, aptitudes, perceptions, insights, and know-how that are implied or indicated but not actually expressed — it resides in individuals & teams. Yes No
Explicit knowledge Knowledge that is codified and conveyed to others through dialog, demonstration, or media such as books, drawings, and documents. Not compulsory Mandatory

Where Waterfall focuses on documentation to transfer knowledge of requirements, knowledge theory notes that much of this knowledge is experiential and therefore not possible to transfer to others in this way [1]. The only effective way to express this knowledge is in the social realm through teamwork and collaboration [2]. Rethinking ‘how requirements are done’ by taking this issue into consideration is needed therefore to decrease the risk of project failure.

Unlike Waterfall, Scrum requires a collaborative and multidisciplinary approach to planning, analysis, design, building and testing. This involves the whole team. In fact, 10% of each Sprint of work in Scrum is dedicated by the team to planning, 10% dedicated to doing analysis and design on scope that is coming up (ie: Backlog Grooming or Story Time), and a whole day reviewing the effectiveness of work throughout the Sprint at its end in order to improve work in the next Sprint. Scrum’s inspect/adapt process (based on the Deming Cycle) ensures that both tacit and explicit forms of knowledge are shared throughout the team for the life of the project.

Because it is not pragmatic to have designers present throughout the build stage of a project, and vice versa, Scrum takes the approach of breaking down all of the requirements into small chunks (Prince2 refers to such small elements as ‘work packages’) that are ranked in their order of value for delivery and asks the team to work collectively on analysing, designing, developing and testing each of those chunks in their rank order. Documentation tends to be light-weight — just enough so that the team has consensus on the issue. Where documentation of a more formal nature is of value to the project it takes the form of another product for the team to produce or becomes part of the acceptance criteria of a product.

The Results of adoption of Agile methods

While it has its naysayers, the CHAOS Report by the Standish Group (2010) show that Agile projects are more successful than Waterfall projects, have fewer challenges and fewer failures.

This is not to say, though, that Agile methods like Scrum are a panacea for all project failures and associated problems. Rigour is still needed in the areas of governance, reporting, and risk management in order to increase the project’s health and assure success.


Many people will still assert that up-front design is required to reduce the risk of project failure. Of course some up-front design is needed before there is confidence enough to start a project in the first place. Sometimes this takes the form of a business case and other times to establish the boundaries of the scope. But in a world where rapid delivery means improved profits, and an improved ability to regularly show business owners and end-users what they are getting (in working form) to improve their confidence that it will meet their needs before the end of the project when everything is completed, I’ll choose Scrum over Waterfall every time.


– – – –

1. Polanyi, M. (1958) Personal Knowledge

2. Nonoka, I. & Takeuchi, H. (1995). The Knowledge Creating Company: How Japanese Companies Create the Dynamics of Innovation