Delivering Business Value

You’ve undoubtedly heard every excuse for why your mission critical project missed a deadline, ran over budget, or no longer meets the needs of your customers. These are all too frequent symptoms of the traditional or “waterfall” approach to software development. Agile development all but eliminates these excuses.

This chart provides a side-by-side comparison between the traditional, phased-based approach, and agile approach to software development as they relate to four key business values.

Business Value

Phase-based (Waterfall) Approach

Agile Approach

Maximize ROI
  • Business must attempt to anticipate all required functionality up front – typically adding many nice-to-have features because they get only “one chance” to define the system they desire. This often leads to asking for “everything” because the business isn’t yet sure which features will end up providing the most value. Then much of what’s built isn’t needed.
  • Difficult to respond to changing business needs.
  • Business determines the most valuable functionality to build at the start of each iteration.
  • Methodology enables rapid response to changing business requirements.

 

Improve alignment of business and IT
  • Business determines all requirements up-front with limited understanding of cost implications. IT is expected to deliver all envisioned functionality within a pre-set budget.
  • Scope/requirements are typically fixed at the end of the requirements phase.
  • Business users are often dissatisfied with final result, even when the system is built according to requirements.
  • Business drives scope, IT provides costs at the feature level. For every iteration, the business determines if functionality is worth the cost.
  • Scope/requirements can change throughout project lifecycle to meet changing business needs.
  • Business users see and use the application frequently, and steer the direction of development.
Ability to monitor solution progress and improve IT accountability
  • Progress tracked against up-front plan.
  • Non-code artifacts (e.g., documents) used as interim deliverables and serve as proxy measurement of progress.
  • Development risks accounted for by building into the project a rough estimate of buffer.
  • Progress measured based upon completed, tested and integrated code.
  • Development risks are understood and mitigated early in project lifecycle.
Ability to justify new and/or continued IT investment
  • Large investment typically required up-front to support year/multi-year efforts based on projected costs/benefits.
  • Gates established every release (3-4 months) for management to determine if continued investment is warranted based on delivered functionality.