Scrum Fills the Leak in the Waterfall Methodology (Part 2)

Read ‘Part 1’ Here.

Although there are many reasons for Waterfall Failure or Waterfall ‘Leaks’, here are some common causes:

Requirements & Scope Control

Requirements tend to be unclear, lack agreement, lack priority, can be contradictory, ambiguous, and imprecise. With that said, Waterfall assumes a detailed set of requirements will be 100% accurate at the beginning and locked for the duration of the project. Changes to requirements are bad and Waterfall tries to minimize once the plan is created.

Planning (schedules & budgets)

Schedules and budgets can be based on insufficient data, missing items, insufficient details, and poor estimates. Waterfall assumes the initial estimates are locked and accurate. Frequently dates and budget are decided well before even project engineers had a chance to provide their own input on estimates.   These same team members are then forced into long spanning timelines they don’t agree with. This can also lead to overly cautious PMs who end up in ‘analysis paralyses’ during the planning phase in an attempt to perfect estimates which can delay the start of the project.

Communication

Another common reason for failure is poor communication and stakeholder engagement. This also causes lack of clarity and trust. Waterfall assumes the PM should plan all the work or tasks (i.e. planning from the center) and the project team must execute the tasks they are assigned. There is no sense of ownership from the team’s perspective.

Customer Value (and quality):

Typically, Waterfall does not provide any value back to the customer until the very end after all other phases. All requirements are locked together as they journey through all the waterfall phases only to realize that what they wanted a year ago is already obsolete and needs changing. Waiting to do the testing until the end of the project risks finding out a major issue right before deployment which will cause the project dates to slide and be over budget. A common waterfall solution to this is to reduce testing effort to ‘keep the dates’ and turn over a poor quality system into production. Read more

Scrum Fills the Leak in the Waterfall Methodology (Part 1)

Although the Agile Methodology has been around for more than ten years, Scrum is still relatively new to most people in the project management field – although it is gaining ground. Scrum is the leading agile development methodology, used by Fortune 500 companies around the world. Not only does it change the mechanics of traditional project management (i.e. waterfall), it’s also a philosophical change for the team that uses it. This article will not go into details on how scrum works, but how the benefits of Scrum fix waterfall shortcomings.

The methodology that has dominated software development projects for decades is called “waterfall.” Winston Royce coined the term in his 1970 IEEE paper “Managing the Development of Large Software Systems” to describe a serial method for managing software projects through the development stages (Requirements, Analysis, Design, Code, Test).   However, Royce himself acknowledges the issues with this process: “I believe in this concept, but the implementation described above is risky and invites failure.” He goes on to actually promote iterative development but that seems to have been ignored (or a less understood concept).

After 40+ years, why doesn’t waterfall work? The articles and statistics are endless…

Studies have shown that in over 75% of the investigated and failed software projects, the usage of the Waterfall methodology was one of the key factors of failure.

A study by McKinsey & Company in conjunction with the University of Oxford of 5,400 IT projects found 17 percent of the large IT projects go so badly that they can threaten the very existence of the company. On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted.

A more recent study by Innotas reports that 50 percent of companies had an IT project fail in the last 12 months.

Read ‘Part 2’ Here.