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

Federal agencies depend on IT to support their missions and spent at least $76 billion on IT in fiscal year 2011, according to a report from the Government Accountability Office (GAO). The catalyst for the study was congressional concern over prior IT expenditures that produced disappointing results, including multimillion dollar cost overruns and schedule delays measured in years, with questionable mission-related achievements. The Office of Management and Budget (OMB) in 2010 issued guidance that advocates federal agencies employ "shorter delivery time frames, an approach consistent with Agile." This ongoing series on the Readiness & Fit Analysis (RFA) approach focuses on helping federal agencies and other organizations understand the risks involved when contemplating or embarking on the adoption of new practices, such as Agile methods. This blog posting, the fifth in this series, explores the Practices category, which helps organizations understand which Agile practices are already in use to formulate a more effective adoption strategy.

A Framework for Determining Agile Readiness

Many organizations have traditionally utilized a "waterfall" life cycle model (as epitomized by the engineering "V" charts). 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. Due to these changes, 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/design artifacts. When some organizations start to adopt Agile, they are sometimes surprised that some of the typical practices of Agile methods are already being performed, which can make the "fit" of Agile easier.

The method for using RFA and the profile that supports CMMI for Development adoption is found in Chapter 12 of CMMI Survival Guide: Just Enough Process Improvement. Adopting new practices like those found in SEI's 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 last 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 accommodate 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 the highly regulated DoD government acquisition environment.

This blog explores how the SEI's work on RFA extends it to support profiling and adoption risk identification for DoD or other government organizations that are considering or are in the middle of adopting Agile methods.

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 this post)
• system attributes (discussed in the sixth post)
• technology environment (discussed in the seventh post)

The 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 your expectation if you were observing a successful Agile project or organization operating in relation to that attribute. For example, an attribute from the Practices category is stated as follows:

A role who is the surrogate for the end users and who has authority over the priority of requirements work off (normally called a Product Owner) is chartered and supported.

Comments: From an Agile perspective, the business/operations part of the organization is the determiner of business value, and therefore a specific role that pays attention to prioritization and backlog refinement is a key construct for Agile teams. The role is not exactly a program manager, not exactly a systems engineer, although it has elements of both. Absence of this role creates problems related to prioritization and focus on the project.

Certainty regarding readiness for Agile adoption increases from early use of the RFA method (before initial pilots) to later use (after two or three releases using the newly adopted Agile method). Certainty also changes with respect to the importance of a specific factor to organizational success.

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 our Agile practices) to organizational adoption success. Later in the adoption process, performing an RFA highlights adoption risk areas that were overlooked during early phases of adoption. The RFA also identifies areas where we now have more data to help guide the organization in developing adoption risk mitigation strategies.

For example, we may not initially understand that the approach to cost estimation in a larger organization doesn't easily accommodate certain Agile practices, such as relative estimation. After one or two pilots, however, we are more likely to understand the impact of relative estimation on our results and develop strategies to help connect Agile estimation practices to those of the larger program. This may no longer be an area of adoption risk, and we 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 Practices category, which deals with development and management practices that reflect Agile principles and tenets.

The Practices Category

This category covers several of the more common practices found within the various Agile methods. Not all practices are used by each method; we would be surprised to see all these practices used simultaneously in a single organization. For instance, pure Scrum does not employ pair programming. Thus, before evaluating this group of factors, analysts should determine which method or combination of Agile methods is being employed. These practices are the core mechanisms for expressing Agile principles. The proficiency level of the team in the practices they have chosen, and the rationale for their particular choice of practices, will influence the level of fit for using Agile methods. For example, an organization that is only using the "pair programming" practice from Extreme Programming (XP) on an occasional basis is more likely to have challenges implementing other complementary practices from XP.

As we have done in previous posts, the following list has both a tag and a statement. The tag is a short title that summarizes the statement and the statement provides a condition or behavior that would be expected to be found in an organization successfully using engineering and management methods consistent with Agile principles as published in the Agile Manifesto.

Test-driven development. Test cases are written before the code is written, and only enough code to verify the test case is produced.

This practice embodies both the early and continuous delivery of working software and continuous attention to technical excellence, according to the first and ninth Agile principles of the 12 Agile principles outlined in the Agile Manifesto. By employing test-driven development, errors are easier to identify.

Short (<6 week) iterations. Iterations in which potentially shippable code is produced are shorter than six weeks in length.

This practice is a reflection of the third Agile principle, which states "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." In the DoD environment, the length of iterations tends toward a longer timeframe (closer to 4-6 weeks). "Deliver" in government settings often means delivering to a sandbox or delivering to a test authority rather than directly to an end user.

Continuous integration. A large part or the entire software system is re-integrated each time a component is added or modified.

The first Agile principle cites continuous delivery of valuable software as the highest priority. This can only be accomplished if the software is re-integrated each time a component is changed. Since the iterations are short, this happens frequently. This environment will most likely be unfamiliar to most personnel who have worked in the more traditional environments, and is highly dependent on appropriate automation for the scale of the project. This practice derives from the XP family of practices.

Prioritized Product Backlog. Requirements are generated and prioritized on a frequent basis by the product owner.

This practice is a result of the second, third, and fourth Agile principles, which discuss welcoming changing requirements, delivering working software frequently, and having business people (e.g., product owners) work daily with developers. This practice allows end users to receive the most important functionality of their system first. Likewise, this practice usually provides the biggest return on investment for the work invested. Most Agile methods explicitly employ a prioritized backlog concept.

User stories. User requirements are provided as user stories that establish what the user needs to do and for what purpose.

Within Agile methods derived from XP, the requirements are represented to the team in the form of a backlog, which is written as user stories. This practice allows developers and users to have an on-going conversation about the requirements as needed. This practice is also a reflection of the fourth Agile which states "Business people and developers must work together daily throughout the project."

Product Owner. A role who is the surrogate for the end users and who has authority over the priority of requirements work off (normally called a Product Owner) is chartered and supported.

Since business people and developers work together daily in an Agile environment, someone on the business/operational side must determine the priorities of the requirements. This role is not seen within traditional environments, but it is part of the commitment of an organization to Agile methods. The Product Owner role is particularly challenging in government acquisition environments that typically have a much more "arm's length" relationship with developers.

Relative estimation. Relative estimation is used to estimate the requirements that the team will accomplish in an iteration.

Typically, absolute estimation is used within the DoD environment since it uses a plan-driven approach that starts long before a program is actually chartered. Agile approaches take a more relative estimation approach to sizing the work by using comparisons to work already done, i.e., is it the same size and complexity, smaller or bigger. Relative estimation is similar to the Delphi method and is based on expert opinion. As a team works together, these relative estimates can become quite predictive of the team's ability to complete their committed work.

Management as Barrier Remover. Management's role is primarily focused on removing barriers to team performance rather than directing the organization of the work.

Within organizations that adopt Agile principles, the manager's role becomes more of a coach or facilitator. The teams are self-organizing in that they determine how they will accomplish the work assigned to them. The assignment of work, via the product backlog, is at the outcome level, with the decomposition into smaller chunks of product and tasks left to the team. This practice is contrary to the more "command-and-control" style of management prevalent within DoD development efforts.

Self-organizing team. The team organizes how the work chosen for each iteration will be done.

The eleventh Agile principle states, "The best architecture, requirements, and designs emerge from self-organizing teams." In Agile, the work is given to the team with high-level descriptions of what is to be accomplished, as opposed to low-level design specifications to be implemented. The team decomposes the work into smaller chunks that can be accomplished within one iteration. The principle of self-organization relies on the concept that the sum is more than the parts. In other words, the team is more than each individual person.

Self-managing team. The team is responsible for how it gets its committed work done, rather than being given low granular tasks.

Part of the fifth Agile principle advocates trusting the team to get the job done. The teams know better than anyone how they can solve a problem. The more encouragement and latitude a team is provided, the better they can solve the technical issues in creative ways.

Pair programming. Programmers work in pairs to achieve their task goals.

The XP Agile method uses pair programming to provide working software faster with fewer defects. Not all Agile teams employ this technique, and it must be learned to be effective.

Daily stand up meetings. Meetings are held daily that deal only with yesterday's accomplishments, today's planned work, and any impediments that need to be removed.

This practice comes from the Scrum method of Agile, and has been adopted by many of the other agile methods. This practice embodies the sixth Agile principle, which states "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

End-Iteration Demos. Demonstrations of the current state of the system are held for the product owner and other stakeholders at the end of each iteration.

This practice reflects the first and seventh Agile principles. The first principle states "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." The seventh Agile principle states "Working software is the primary measure of progress." These demonstrations show the stakeholders actual working software, not necessarily the whole system, but a particular slice of it. This is one of the main tools teams can employ to convince stakeholders of the benefits of Agile.

End-Iteration Retrospectives. At the end of each iteration, a team meeting is held to reflect on what went well and what could be improved from the last iteration.

The twelfth Agile principle states "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." This practice is an effective tool that allows the team to do continuous process improvement as the program progresses.

As we learn more about effective Agile practices in use in government settings, this list will expand.

Looking Ahead

Many other factors influence readiness in the practices category. Several have been discussed in prior blog posts already. The ones discussed in this posting, however, most closely reflect actual practices in the field. By paying attention to them when considering your readiness and fitness for Agile adoption, you can realize more successful pilots and implementations. Each category in the RFA offers insight into the risks that an organization will face when adopting Agile methods. Identifying these risks is an important first step in planning and executing mitigation strategies to address them.

In the next post in this series, I will delve into two other important, though shorter, RFA categories: technology environment and system attributes. These categories address factors related to management and technical tooling available for Agile development, as well as factors related to the character of the project being undertaken.

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.