Uncertainty is Certain: A Case for Agile Development Practices

Updated: December 27, 2010

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.


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.
Featured Research
  • Contact Center Software on a Budget

    Although contact center software is necessary for a modern contact center, it can be outrageously expensive. Many companies find that their budget bloats during the implementation process. more

  • How UC Can Help Your Business Survive the Holidays

    The holiday season is filled with frenzy and excitement for businesses and consumers alike. Consumers prepare gift lists, compare brands and prices, and begin shopping with a vigor that is not present most other times of the year. For many businesses, the holiday season accounts for a large profit bump at the end of each year, and companies strive to exceed their goals and keep customers happy during this rush late in the year. more

  • [Infographic] Switching Phone Systems

    There are a lot of possible reasons you might want to switch to a new phone system. The old one might cost too much or be too troublesome to operate and maintain. It might not be flexible enough. It might not be reliable enough. Or it just might not have the kinds of features and capabilities that you need in today’s competitive business climate. more

  • Business Intelligence Software Cost Guide

    Your choice in a BI (Business Intelligence) provider can lead you to make better, data-driven decisions for your business, resulting in significant ROI. Or it can cost hundreds of thousands of dollars with mixed results. more

  • The New 2016 ERP Comparison Guide

    Selecting an ERP solution is no easy undertaking. You have to select and configure a system that fits your exact business needs. The right system can make operations more streamlined, efficient, and agile. But choosing the right vendor can be difficult. more