Time for program managers to embrace agile development

By Rodney Bodamer

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 reexamine how we partner with our government clients.

In reality, few major government IT programs are equipped to address and respond to the inevitable change that these efforts entail. So, what’s the solution? By embracing agile development practices, we can meet our client’s expectations around value and functional capabilities more effectively, despite often changing requirements. This is a result of empowering our clients to make the strategic decisions and priorities required to move the project forward quickly without sacrificing quality.

Let’s put this issue into perspective: 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.

Balancing Competing Demands

Every project is governed by three constraints – time, budget and the desired set of features and functions. When unforeseen contingencies arise – as they always do – one or more of those parameters needs to change. Is your customer dead set on a specific set of features and functions regardless of the development obstacles? As most program managers can attest, in that scenario prepare to increase your budget and/or timeline accordingly.

Agile development practices take a slightly 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.

The ability to readily accommodate change is one of the principal values of agile development. Using this more incremental, collaborative and empirical model, functionality is quickly developed in “bite size chunks” and tested by the customer for adherence to both business and technical requirements. Should changes be required, they can be more quickly assessed in importance, prioritized and integrated into the solution, resulting in less impact on the delivery timeline and budget. Likewise, deficiencies can be exposed and remediated earlier in the process when it is less costly to do so. Through this more iterative process, organizations also are able to maintain better line-of-sight alignment with overriding business objectives.

In contrast, 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.

Real-World Benefits

Of course, some would argue that we are simply replacing the current problem of budget overruns and product delays with a new challenge of incomplete applications. That’s not the case. As agile frameworks such as Scrum are predicated on the delivery of functional software components, we are actually providing new capabilities sooner than otherwise possible. And while some functionality may be eliminated from the final product to comply with time and budget constraints, they are often, by definition, extraneous features because development priorities address the most critical requirements first.

Unlike traditional models, agile development practices allow you to capitalize immediately on what’s already been developed even if you elect to expand the development timeframe or budget. Likewise, agile recognizes that most applications will be continually refined as new requirements are identified. Instead of an all or nothing model, apps are updated and upgraded with each subsequent version.

The Scrum framework for agile development was used under the Federal Health Architecture initiative to create the Connect gateway for the Nationwide Health Information Network. Despite a six-month delay in initiating development, the team was able to meet every deadline; the initial release was delivered in only five months. Equally significant, the team has continued to layer new features and functionality on to the platform with three releases delivered so far this year.

Making Agile Part of Project Management

The principal 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.

Rodney Bodamer is a program manager with Agilex Technologies where he leads software development engagements in the healthcare sector.