Agile Development – Does it really deliver?

The phrase “on-time, on-budget and on-scope” is fundamental to almost every government contractor’s value proposition because it defines successful program delivery. However, its validity is frequently undermined by the poor performance of major government IT programs. While contractors alone aren’t fully responsible for program success or failure, the increased scrutiny that we face provides an opportunity to look at how we partner with our government clients.

By embracing agile development practices, can we can meet our client’s expectations around value and functional capabilities more effectively, despite often changing requirements?

One recent article talks about the fact that, Roger Baker, chief information officer at the Veterans Affairs Department, won notice earlier this year for placing 45 IT projects on hold. Although many observers were surprised by the number of major software projects that were over budget, behind schedule or both, they shouldn’t have been surprised at all.

According to a 2008 report by the Standish Group, only a minority of all IT projects were on track when measured objectively:

• 32 percent of all projects were found to have been delivered on-time, on-budget and with the required features and functions
• 44 percent were challenged, which meant that they were late, over budget, missing features and functions, or some combination of those factors
• 24 percent simply failed, which meant they were either cancelled or delivered but never used.

This situation is particularly acute in the government sector, where contracting provisions and traditional software lifecycle processes force organizations to embrace a “big bang” approach to application development. In that scenario, one project group creates an exhaustive list of requirements, which is then turned over to a team of developers and testers with the hope that they will return in several years with a functioning application that meets the specifications and expectations of the end user.

But as we have seen in case after case, the needs and requirements of the customer change over time and lessons learned along the way fail to be incorporated into the final release. This occurs because traditional methodologies fail to respond to those changes as requirements are generally locked down at the beginning of a project, and with minimal customer involvement and interaction during the subsequent project execution. As a result, what we are often left with is a solution with incomplete or missing features that doesn’t meet the ultimate needs of the customer despite years of development.

Agile development practices take a different tack. They make the scope of the project variable while adhering to the original cost and deadline specifications. Although this may sound counterintuitive at first, in reality there is a strong rationale behind it. With any project, it’s impossible to fully scope every requirement in advance because the development process will influence a number of subsequent decisions. Indeed, requirements continue to evolve over the course of the project as the team learns more about the end user’s business case. At the same time, customers get to see and interact with an actual working product, allowing them to determine if it meets their expectations and assumptions. Also project priorities might change over time.

Unlike this, the sequential waterfall model that drives most traditional development approaches makes after-the-fact changes difficult if not cost-prohibitive. So when the inevitable changes do arise, the project’s timeline and budget quickly spiral as planners need to retrofit the new requirement into each step of the development process.

Agile development practices also reflect the changing nature of application development. Driven by the emergence of Software-as-a-Service (SaaS), Service-Oriented Architecture (SOA) and common standards, users are implementing new features and functions as they are developed and tested, rather than waiting several years for the full product to be completed. As a result, incremental business value and return on investment are realized earlier as intermediate steps in the process are automated even if the end-to-end process isn’t fully integrated yet.

Making Agile Part of Project Management

The main concern regarding agile development practices is the perception that it is not compatible with existing management approaches such as Project Management Body of Knowledge, (PMBOK), earned value management (EVM) or CMMI. The reality is it is not meant to be a replacement and is an excellent complement to each of those models. Most important are the enhanced accountability and traceability that agile development practices deliver as each major decision is made openly and collaboratively.