One of the key differentiation points with agile methodologies that may not be immediately apparent is the amount of time the product owner and engineering teams spend analyzing requirements. The engineering team spends the entirety of the requirements phase developing an understanding of the requirements, and also gets to clarify and develop their understanding through the construction phase as well. One key point is that the product owners had a much shorter time limit to develop their requirements, ideas and solutions: they were "timeboxed" into the requirements phase. One of the key benefits of agile, which I believe isn't always expressed, is that the product owner will have the same opportunity to analyze, digest and understand the requirements of the platform as the engineering teams - for the entirety of the project. The idea embedded into the SCRUM approach specifically, works to enhance the job of partnering the requirements owner with the engineering teams for the life of the project. Working together throughout the course of the project on requirements refinement becomes the proficiency of the entire team.
Over the years numerous techniques have been developed to address the deficiencies inherit in the waterfall method. Some commonly seen deficiencies by phase are:
For requirements engineering:
For the development cycle:
While having participated in projects where the engineering team failed to fully understand the requirements of the product owner is certainly not a rare occurrence, there have been great improvements in this area through team-centric process improvement.
ADDRESSING SHORTCOMINGS
Waterfall projects traditionally develop many of the same ad-hoc remedies to deal with issues imposed by the timeboxing of the requirements and development, errors in requirements definition or understanding, and even to accommodate for coding errors. We often perform one or more follow on releases to address these shortcomings. These can be in the form of "Phase 2" releases, "enhancement" releases or just subsequent versions of the project. In doing this, these projects naturally follow the same waterfall process. This is repeated until everyone is satisfied, or we no long have resources available to do so. In our attempt to timebox different phases of the project, we planned on getting everything right the first time, without error. When we can accomplish this, it is a great success. Too often, however, product owners are left waiting for "Phase 2".
One alternative approach is to simply remove the divide between the product owner and the engineering team. What if, through the entirety of the project, the product owner was an integral part of the engineering team? Project managers work towards getting the entire team motivated, headed in the same direction, and more importantly interested in the success of the project. If everyone were tied to the overall success of the project, rather than the deliverable for a particular phase of the project, would this lead to greater commitment from everyone for the duration of the project? Modern methodologies such as Scrum do just this. Instead of attempting to gather and digest all of the requirements at once, the team can now take them a piece at a time. Anything that is not yet fullyunderstood sits on the shelf while the team works through issues that are understood and can be managed. This accomplishes a few things: