This blog post is the sixth in a series on Agile adoption in regulated settings, such as the Department of Defense, Internal Revenue Service, and Food and Drug Administration.

"Across the government, we've decreased the time it takes across our high-impact investments to deliver functionality by 20 days over the past year alone. That is a big indicator that agencies across the board are adopting agile or agile-like practices," Lisa Schlosser, acting federal chief information officer, said in a November 2014 interview with Federal News Radio. Schlosser based her remarks on data collected by the Office of Management and Budget (OMB) over the last year. In 2010, the OMB issued guidance calling on federal agencies to employ "shorter delivery time frames, an approach consistent with Agile" when developing or acquiring IT. As evidenced by the OMB data, Agile practices can help federal agencies and other organizations design and acquire software more effectively, but they need to understand the risks involved when contemplating the use of Agile. This ongoing series on Readiness & Fit Analysis (RFA) focuses on helping federal agencies and other organizations in regulated settings understand the risks involved when contemplating or embarking on a new approach to developing or acquiring software. Specifically, this blog post, the sixth in a series, explores issues related to system attributes organizations should consider when adopting Agile.

A Framework for Determining Agile Readiness

Many organizations, especially in the federal government, have traditionally utilized a waterfall lifecycle model (as epitomized by the engineering "V" charts) for software development. Programming teams in these organizations are accustomed to being managed via a series of document-centric technical reviews, such as design reviews. These reviews focus on the evolution of artifacts that describe the requirements and design of a system rather than its evolving implementation, as is more common with Agile methods. Because of this significant difference in focus, many organizations struggle to adopt Agile practices and find it hard to prepare for technical reviews that don't account for both implementation artifacts and the availability of requirements and/or design artifacts that are at different levels of abstraction. On the other hand, some organizations are surprised to discover they are already performing some of the practices of Agile methods, which can ease Agile adoption.

The method for using RFA and the profile that supports CMMI for Development adoption are found in Chapter 12 of CMMI Survival Guide: Just Enough Process Improvement. Adopting new practices like those found in CMMI models involves adoption risk, as does the adoption of many other technologies. I first used RFA in the 1990s to identify adoption risks for software process tools. Since that time, I have used RFA to profile various technologies, including CMMI and, now, Agile.

For the past several years, the SEI has researched adoption of Agile methods in U.S. Department of Defense (DoD) and other government settings. SEI researchers have adapted the RFA profiling technique to include typical factors related to adopting Agile methods for any setting. We have also focused on other factors more uniquely associated with adopting Agile methods in highly regulated government acquisition environments, such as the DoD and Department of Homeland Security.

This series of blog posts characterizes six categories to profile for readiness and fit:

• business and acquisition (discussed in the first post)
• organizational climate (discussed in the second post and continued in the third post)
• project and customer environment (discussed in the fourth post)
• practices (discussed in the fifth post)
• system attributes (discussed in this post)
• technology environment (discussed in the seventh post)

Categories and factors continue to evolve as we pilot the analysis in client settings, but these six listed above are the ones we are currently using.

Applying the Readiness & Fit Analysis

Each category of readiness and fit has a set of attributes that can be characterized by a statement representing the expected behavior of a successful Agile project or organization operating in relation to that attribute. For example, an attribute from the system attributes/technology category is stated as follows:

Loosely-coupled architecture. Product architecture allows for at least some of the components to be produced independently (architecture reflects loose coupling).

Application Notes:

At the beginning of an Agile adoption project, organizations are often uncertain about their current state in terms of adoption factors or the importance of individual factors (such as alignment of oversight practices with Agile practices) to organizational adoption success. Later in the process, an RFA can highlight adoption risk areas that were overlooked during earlier phases of adoption.

Using the example above, an organization may have an architecture already in place when it considers adopting Agile practices that is not loosely-coupled and contains many dependencies. This will make it harder to create independent slices of functionality. There will be inherent rework because of architectural dependencies as the system evolves. After one or two pilots, however, the impacts of the tightly coupled architecture may motivate a strategic pause to explicitly rework the architecture to more readily accommodate incremental, iterative Agile approaches. After that re-architecting, this would no longer be an area of adoption risk, and the organization can move on to dealing with other issues. The key point here is to be prepared to apply RFA principles and techniques at multiple points in your adoption journey.

The remainder of this post is dedicated to the System Attributes category.

The System Attributes Category

System attributes cover technical aspects of the product under development and determine whether work benefits from division into smaller chunks that can be produced iteratively and built upon over time. If the program cannot be broken into loosely coupled, smaller chunks, then it will be hard, if not impossible, to produce "slices" of functionality that can stand alone and provide usable functionality at the end of each iteration. Each iteration in an Agile development effort ideally produces potentially shippable code (not always to external customers, it could be for internal customers). This production of usable functionality frequently means that someone could deploy and use the code to achieve some tangible benefit prior to the entire product's completion. As in other RFA categories, the following list has both a tag (a short title that summarizes the statement) and a statement that provides a condition or behavior one would expect to find in an organization with successful engineering and management methods consistent with Agile principles, as published in the Agile Manifesto.

Loosely-coupled architecture. Product architecture allows for at least some of the components to be produced independently (architecture reflects loose coupling).

From an Agile perspective, a loosely-coupled architecture has two implications. First, in an Agile environment, each iteration should yield potentially shippable code. With a loosely-coupled architecture, a component can be produced independently, and it should be easier to produce something usable within one iteration.

Second, in today's environment, especially for large DoD programs, the staff is distributed across multiple locations. While modern communications supports the use of Agile methods in these distributed environments, it is easier for one team to be responsible for an independent module with loose coupling than for a module with many interfaces requiring significant communication and collaboration.

System supports iterative delivery. System or service type is compatible with an incremental release and delivery strategy.

The third Agile principle states, "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." If the strategy for the system or service type is based on a strategy that requires a plan-driven, documentation-centric approach--complete with multiple milestones, large reviews, and "big bang" integration--then the shorter iterative approach will be incompatible and potentially cause additional work and many disconnects throughout the development.

Critical dependencies accounted for. Mission and safety-critical components and dependencies are identified and accounted for in the program strategy.

Agile programs deliver working software frequently. If mission and safety-critical components and dependencies are not identified and accounted for in the program strategy, however, the software could easily be incomplete and cause significant rework. In fact, the ninth Agile principle states, "Continuous attention to technical excellence and good design enhances agility." This principle means that the critical components and dependencies should be considered up front. This principle also relates to the importance of paying close attention to architecturally-significant requirements as part of the early activities. Some programs deal with this in a "Sprint Zero" before the actual software development begins. Others use the concept of an architectural runway to ensure that dependencies and interfaces are understood to a useful level before implementation decisions are made.

Security requirements accounted for. Security drivers are accounted for in the program strategy.

As with critical dependencies, continuous attention to technical excellence and good design requires the developers to consider security requirements up front and throughout development. This consideration is particularly true with DoD or other complex programs (also found in healthcare, medical devices, and financial systems, to name a few) that have complex security requirements.

Failure cost accounted for. Cost of failure is understood and accounted for.

Failure can take on many forms--working software that does not deliver the needed functionality, late software deliveries, or software development that is incompatible with the rest of the organization. The 12 Agile principles counter these issues. However, the organization must take into account Agile development activities with relationship to the overall project and to the organization's culture. If these relationships are not in sync, the overall Agile project could be in jeopardy.

Appropriate criticality. Criticality of the software in meeting business or mission goals is addressed for the program.

Many teams embrace Agile methods because the software is needed quickly or provides a competitive advantage. If the criticality attribute of the requirements is not prioritized appropriately, however, even software delivered early and often may not provide the required functionality. Sound engineering principles are still required when employing Agile methods, as emphasized in the first part of the ninth Agile principle "Continuous attention to technical excellence..."

The system attributes category may be smaller in terms of the number of attributes addressed, but is an important area for successful Agile adoption. The next post in the series will present the final category in this series on RFA, technology environment, and complete our whirlwind tour of the six categories in the Agile Adoption in DoD RFA model.

I look forward to hearing your experiences adopting Agile methods, especially those operating in regulated environments. Please leave a comment below or send an email to info@sei.cmu.edu.

Additional Resources

Read all the posts in this series on the Readiness & Fit Analysis method.

Read a white paper about the Readiness & Fit Analysis method.

For more information on management and acquisition considerations in using agile methods in DoD environment, please our first two technical notes in the Agile Acquisition series:

Agile Methods: Selected DoD Management and Acquisition Concerns

An Acquisition Perspective on Product Evaluation

Listen to a series of podcasts that I recorded with Mary Ann Lapham exploring the real-world application of Agile principles in the DoD.