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.

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.
Featured Research
  • Best ERP Features and Benefits for Your Business

    Are you considering investing in ERP software for the first time? Or maybe you already have an ERP solution but you’re worried it’s becoming dated. If either of the above apply to you, read our latest guide on the top ERP features and benefits based on the size of your business. You may be surprised at how versatile and cost-effective it is becoming - regardless of if you own a small business or run a large enterprise. more

  • 9 Spooky Signs You Need a Contact Center Upgrade

    When was the last time you evaluated the performance of your current contact center and the software you are using? The results may be frightening! If it’s been awhile since you invested in contact center software, there is a good chance that your needs have changed or that there are better options available now. Fortunately, it’s relatively easy to determine if you need an upgrade or not. more

  • 7 Ways the Wrong Phone System Can Haunt Your Business

    The wrong phone system could be haunting your business - and we’re talking about problems more serious than ghosts and ghouls. From increased costs to issues with scaling, we’ve identified seven important ways that a less than ideal phone system could be holding you back. You’ll be surprised at how much of a difference this can make to your bottom line too. more

  • Ditch Your Fax Servers

    An in-house fax server gives an IT department centralized management and monitoring over the entire enterprise's faxing. This can help your company track usage and better maintain records for auditing and record keeping. However, there are serious drawbacks that come with utilizing an in-house fax server solution and these range from security to cost-prohibitive pricing. more

  • The IT Manager's Survival Guide

    As an IT manager, maintaining physical fax servers and infrastructure is not a high priority. However, fax capability remains a business need simply because chances are your industry is dependent on its security. What if there was a way to reduce the amount of time spent handling fax complaints and maintaining physical servers? And this way took into account security, cost savings, and freed up your IT resources. Would you be interested? more