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

Organizations and federal agencies seeking to adopt Agile often struggle because they do not understand the adoption risks involved when contemplating the use of Agile approaches. This ongoing series on Readiness and Fit Analysis (RFA) focuses on helping federal agencies, such as the Department of Defense, the Internal Revenue Service, the Food and Drug Administration, and other organizations in regulated settings, understand the risks involved when contemplating or embarking on a new approach to developing or acquiring software. This blog post, the seventh in a series, explores issues related to the technology environment that organizations should consider when adopting Agile approaches.

A Framework for Determining Agile Readiness

The fifth principle of the Agile Manifesto states: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. A key component of this principle focuses on the technical environment, which includes existing or planned technologies to support the selected Agile methods. In 2010, the Office of Management and Budget (OMB) issued guidance calling on federal agencies to employ "shorter delivery time frames, an approach consistent with Agile" when developing or acquiring IT. OMB research has noted that Agile practices can help federal agencies and other organizations design and acquire software more effectively.

However, many organizations, especially in the federal government, have traditionally used a non-iterative version of the waterfall lifecycle model 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.

Due to these significant differences 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. Although the profile in the book focuses on CMMI, not Agile, the steps in conducting Readiness and Fit Analysis also apply for Agile. 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 software and practice-based technologies, including CMMI and, now, Agile. The diagram below provides an overview of the basic steps in conducting RFA:

Note that this technique not only focuses on gaps, but also on generating adoption risk mitigations and taking a stab at an initial roadmap. The data gathered in the first instance of application also serves as a baseline against which adoption progress can be measured, if desired.

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

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

Applying the Readiness & Fit Analysis

Each readiness and fit category 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 technology environment category is stated as follows:

Technical Tools Support Agile: Tools that are critical to supporting a particular Agile/Lean method are available and integrated into the program technology environment (e.g., automated testing suite, continuous integration support tools).

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.

As the organization's adoption progresses, some risks will have been avoided; others will have been mitigated or solved before they have a negative impact. Some risks will manifest, but their impact is reduced by awareness and actions taken, and some will manifest and have the predicted negative impact. RFA does not assume that an organization can mitigate or avoid all risks. This approach assumes that the organization, on an ongoing basis, wants to understand the mismatches between an ideal environment for pursuing Agile approaches and the organization's current state. Then the organization can make more informed decisions about how and when to pursue different aspects of Agile methods.

The remainder of this post is dedicated to exploring the final RFA category, technology environment.

Technology Environment Category

The technology environment is an important fit element because it creates the setting for the execution of the project. Project execution can be inhibited by both project management tools and tools in the development environment. Tools for Agile projects may be different from the ones possessed by traditional organizations.

This category is the shortest of the six RFA categories because it's hard to be specific about particular tooling support requirements until the current technology environment of the development environment is understood. Agile tools (both technical and management) need to integrate with the overall application lifecycle management (ALM) tools used by the organization to develop, document, and manage its work products.

It is interesting to reflect upon the need for appropriate tools to effectively implement Agile approaches when the Agile Manifesto itself has a tenet "Individuals and interactions over processes and tools". At the time the Agile Manifesto was written, however, integrated development environments emphasized documentation of design and data models over tools that emphasized practices such as writing and conducting tests (a necessity in any professional development organization) or allowing multi-thread continuous integration.

For teams that don't already have technology environments that support fast-build, continuous integration activities, building the software every time you commit code to the repository is difficult to achieve.

In part, one could argue that the growth of the tool industry in these two particular areas--automated regression testing tools and continuous integration support tools--could be due to the need for those kinds of tools to support the speed of Agile development.

Technical tools support Agile. Tools that are critical to supporting a particular Agile or Lean method are available and integrated into the program technology environment (e.g., automated regression testing suites and continuous integration support tools).

Agile methods deliver software frequently. To ensure quality products are produced during this fast delivery cycle, the software is integrated and tested frequently--usually daily. This integration and testing quickly become prohibitively labor-intensive without appropriate tools. The two classes of tools mentioned above--automated regression testing tools and continuous integration support tools--are worth thinking about when contemplating adoption of Agile methods, especially in regulated settings where tools are often one of the areas where regulation is robust.

From the acquirer's perspective one of the particular challenges for technical tool sets, is ensuring that those tool sets and their data are made available to the customer organization that will be sustaining the product. Reinventing the regression test suite and not having the right integration environment can significantly slow down the sustainment activities that are needed after deployment of the system.

Project tools support Agile. Project management tools that support chosen Agile or Lean methods are available and integrated into the program's technology environment.

Agile projects are empirical and may not use the traditional program management tools, such as Gantt charts or Microsoft Project files, as their primary representation of progress. Agile programs typically use burn down or burn up charts, track tasks to sprints, etc. Commercial vendors provide many tools to help automate this tracking. While it's possible to manage Agile projects without these tools, additional work may be required. A cost-benefit analysis should therefore be conducted for the program.

One typical issue in acquiring organizations is access to the Agile management project tools being used by the contracted developer. Although access to these tools creates a pull environment for management data (the acquirer pulls data as needed, rather than creating specific reports on a defined schedule), many contractors who have not worked in this type of environment fear that acquirer organizations will use the data to inappropriately micro-manage the development teams. Fear of data misuse is one of the risks that should be identified if it exists in the program.

The robust Agile team management tooling environment offers many choices. The SEI does not advocate the use of particular tools; however, we do advocate analyzing your current project management tooling and looking for opportunities to give your Agile programs tools that are aligned with Agile principles and practices.

Project technology basis is accounted for. Team understanding of the project's technology environment is sufficient to understand architectural and user implications for breaking the project down into feasible chunks.

The team must sufficiently understand the project's domain and its technology environment to account for architectural and user implications for breaking the project down into feasible chunks and for rank ordering the backlog items. Just as with traditional environments and their associated tools, the team needs to be trained in the relevant aspects of their technology environment. At a minimum, additional work or misuse of the tools could result from insufficient training. A worst-case scenario is that a team that has insufficient understanding of the project's technologies could make serious errors in breaking down epics and stories into the releases and iteration backlogs.

Wrapping Up and Looking Ahead

This post concludes our tour of Agile adoption risk factors the SEI has found to be meaningful in organizations operating in regulated settings attempting to adopt Agile methods. No single organization will have problems in all of these areas, nor is any organization considering adoption of Agile methods likely to find all of the factors already in alignment with their organization's culture and practices. We therefore suggest going in with your eyes wide open to understanding your own organization's adoption risks and then explicitly constructing actions to mitigate them. In our experience, organizations that take these risks seriously and make sincere attempts to mitigate identified risks have fewer surprises in the Agile adoption journey.

I look forward to hearing your experiences adopting Agile methods, especially those of your 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.