Uncertainty is Certain: A Case for Agile Development Practices
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:
- The product owner may fail to enumerate requirements
- The engineering team may fail to fully develop or understand requirements
For the development cycle:
- The development team may introduce coding error
- The development team may not meet established schedules
- The development team mot create a solution that meets the requirements
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:
- It allows understood features to be built and delivered. Whether the end user can make use of parts of the new functionality, or simply by getting features into testing sooner, progress is more easily discernable and monitored.
- It allows the product owner and engineering team to work through issues together. Immersing the product owner into the cycle, keeps visibility on issues that need to be ironed out with more detail in the requirements (user stories, perhaps), and just as importantly it helps the product owner to work through requirements issues that he may not be able to articulate in the first month of the project. Increasing the time allowed to articulate requirements from a beginning phase of the project to the life of the project will undoubtedly increase accuracy and overall understanding.
- It gets the whole team into a cycle of producing requirements, developing changes, and implementing them. With this repetition comes competency. Greater efficiencies will be developed in working through tough issues a piece at a time.
