Debate: Is government's accountability obsession ill-suited to agile development?

President Barack Obama’s 25-point plan to reform federal IT management calls on agencies to take a more modular approach to developing new IT systems rather than pursuing the predefined, monolithic designs that government typically favors.

But some question whether government’s accountability-intensive project management style is suited to agile development, which emphasizes iterative development and incremental releases of new capabilities. In particular, they wonder whether agencies can break the habit of producing extensive system specifications at the beginning of a project, which the traditional waterfall style of development requires.

Federal Computer Week asked two software industry veterans to address the question. Jason Moccia, president and co-founder of OneSpring, argues that the issue isn’t about when user requirements are defined and captured as much as it is about how that process happens.

Larry Albert, president of the health care sector at Agilex Technologies, acknowledges that agile development will require some changes in how agencies create project specifications but says the difference is less significant than skeptics would have us believe.

Moccia: Holistic approach needed

The government’s 25-point plan for reforming IT management has made agile more popular than ever in Washington, D.C. I am currently evaluating several federal agencies that are attempting to adopt agile and have seen some patterns emerge that require further analysis and reflection.

One item relates to how requirements are captured and managed within an agile framework — not only at the development level but across the organization. The traditional approach to defining and managing requirements does not fit well into an agile model; however, it is the norm for most large-scale software projects, especially if organizations have been following a waterfall methodology for years.

There are two groups within organizations that must cooperate in order for agile to work properly: business and IT. The business side is primarily responsible for building the business case for a proposed software application, which includes how the project will meet organizational goals and objectives. IT is responsible for building the application within the defined budget, time and scope.

Unfortunately, there’s a misalignment between IT departments that are attempting to implement agile development and the business side that defines what needs to be built and the internal processes that must be followed.

In government software development, the business side of an agency is still responsible for producing the same artifacts they have always produced and passing the same software life cycle management tollgates. Organizations cannot successfully adopt agile at the IT level without changing their mind-set of how the business side functions. That paradigm has created a disconnect between organizations looking to adopt agile within traditional business operations.

A more holistic approach would help. One immediate opportunity occurs when the business side passes the requirements specification for a software application to the IT team to build. If an agency sends traditional specifications to an agile team, the results are typically negative. Most agile teams will want to start over by creating what are called "user stories" in agile parlance. That creates a tremendous amount of rework and churn, which usually leads to frustration on the part of the business employees because they have to rehash what they’ve already spent a lot of time putting together.

The solution is to come up with a decomposition model during the handoff period. Decomposition is a process in which the business side and IT decompose the requirements specifications together to convert them into the proper format for agile development. The goal should be for the business to get the requirements 70 percent to 80 percent complete then use the decomposition phase to finish the requirements with the IT staff.

That approach would improve the odds of a successful outcome while also reducing risk. First, it allows the business employees to work with technical experts to further analyze and synthesize the requirements they’ve defined thus far. Second, it gets the developers engaged in the requirements discussion earlier rather than doing a single handoff at the end of the requirements phase. Third, it allows team members to build relationships with one another. Fourth, it allows the team to address usability questions and requirements before development begins.

Agile cannot be rolled out in a silo; it must be woven into the organization at all levels. Bridging the gap between business and IT has been an issue for decades, and the advent of agile has made it an even more pressing concern. Change needs to occur at all levels of the organization in order to achieve the benefits of adopting agile.

Albert: Don't buy the misconception

The belief that agile methodologies limit upfront requirements documentation is a common misconception. In reality, documentation remains a critical component, with detailed specifications developed in advance to the fullest extent possible. Where agile differs is in embracing a process that does not require detailed documentation of all requirements to initiate the effort. Instead, it works relentlessly to improve the documentation as the project progresses.

The challenge with traditional development is that critical decisions are made at the onset of a project, when the least is known about the actual requirements. Projects often adhere to those initial specifications even when the need for subsequent changes has become apparent. In determining the desired scope of their upfront requirements documentation, agencies need to consider not only the fairly significant cost and time required to develop it, but also the impact poorly defined requirements will have on the success of their projects.

In contrast, agile recognizes the difficulty in fully and accurately defining a project prior to development. Instead, it relies on an iterative process that uses empirical analysis to continuously refine the specifications and improve the deliverable. That pragmatic approach is important for several reasons. As the solution is developed, stakeholders can more effectively conceptualize it and refine their priorities accordingly. Likewise, business needs continue to evolve, meaning that requirements will change. Furthermore, programming and testing will uncover challenges unforeseen in the initial planning process.

Not surprisingly, agile's approach to requirements documentation is also iterative. Using feedback from each sprint and each release, that living document is updated regularly with greater detail and specificity. The approach ensures that important decisions are not made prematurely and yields more accurate documentation.

Beyond guiding development, requirements documentation is important for managing projects from a contractual perspective. Specifically, it provides the criteria for assessing achievement of key milestones. Without detailed information, many experts say it is impossible to hold project teams and contractors accountable. As a result, some have real concerns about minimizing that requirement.

The reality is that agile holds them more accountable than ever. For example, it relies on integrated design, development and testing teams to deliver working software every two to four weeks. Instead of continuing to push unresolved problems down the pipeline, agile ensures that they are caught early in the process and fixed. The empirical approach to measuring the ongoing development pace also provides a more accurate metric for progress.

Many metrics are being used to adapt traditional, waterfall-based contracting milestones to agile projects. For example, agile releases are based on a specific amount of functionality delivered by a set date. By focusing on parameters such as function points rather than specific features, users can more readily accommodate changing requirements while maintaining the existing scope of the release.

Federal agencies are embracing the flexibility that agile offers. The Defense Department and the Office of Management and Budget have decreed that software development projects must embrace iterative delivery models, with major agencies, such as the Veterans Affairs Department, making enterprise adoption of agile a strategic priority.

Many have overstated the challenges in embracing agile. Although it requires some modest changes to the status quo, agile delivers greater accountability and transparency. Furthermore, emerging technology paradigms, including mobile and cloud-based technology, are making agile development an imperative due to their demands for iterative delivery and continuous improvement. Fortunately, early adopters are demonstrating that agencies can make the transition successfully.

There are ways to improve the upfront process requirements documentation. Tools such as visualization and joint application design sessions can minimize the miscommunication that plagues many projects. I would also stress the value of including the procurement staff in those discussions.

The participants reply

Moccia: Requirements definition is the snag

It is true that agile allows for documentation to occur iteratively. However, requirements definition at the project level is only one facet. Most large projects go through months or even years of planning and defining prior to initiating development. In many cases, program offices separate the requirements effort from development, which further complicates the problem.

The fact remains that the way the federal government develops new systems is highly dependent on a waterfall approach. The focus should be on evolving the way organizations define requirements at a program's onset so that risks and costs are reduced, which means coming up with better ways for stakeholders to validate requirements earlier in the life cycle.

New techniques and technologies allow project teams to define requirements iteratively and early. One such technique is called visualization, a process by which software is defined visually rather than textually. It is similar to rapid prototyping but without producing code. Visualizations of business processes, user interfaces and data can be created in a fraction of the time it takes to program actual code and can occur in real time with stakeholders. Critical decisions can be validated, tested and refined far in advance of development taking place.

Albert: Disconnect overstated

Jason’s solution suggests that our current disconnect is simply a difference in language to be reconciled when, in fact, waterfall and agile are radically different approaches. By design, waterfall is a highly regimented and rigid approach in which requirements are locked in prior to development. Because the process doesn’t readily accommodate change, cost overruns and delays are common.

In contrast, agile requires close and ongoing collaboration between business and IT for the entire development life cycle. It facilitates continuous improvements in the requirements documentation and solution. Specifically, projects can more easily incorporate new requirements, update feature sets to reflect changing priorities and seize additional opportunities to improve the solution. Furthermore, agile doesn’t require complete documentation to initiate development, which is a benefit in some cases.

Effective collaboration requires a shared methodology, with resistance to change overcome by educating stakeholders about agile’s benefits and rationale. By starting small with targeted pilot projects and building incrementally on successes, agencies will have capitalized fully on agile's potential.