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

In our work with the Department of Defense (DoD) and other government agencies such as the U.S. Department of Veteran Affairs and the U.S. Department of the Treasury, we often encounter organizations that have been asked by their government program office to adopt agile methods. These are organizations that have traditionally utilized a waterfall lifecycle model (as epitomized by the engineering "V" charts) and are accustomed to being managed via a series of document-centric technical reviews that focus on the evolution of the artifacts that describe the requirements and design of the system rather than its evolving implementation, as is more common with agile methods.

After the program office and contractor are trained, they realize that there is more to an agile approach than frequent, small iterations and daily standup meetings. As a result, they struggle to adopt agile practices. This post is part of an ongoing series on the Readiness & Fit Analysis (RFA) approach, which helps organizations understand the risks involved when contemplating or embarking on the adoption of new practices, in this case agile methods. This posting continues our exploration of organizational culture, one of the most challenging factors to assess when considering agile adoption readiness.

The first post in this series outlined the principles of RFA and described our work in extending RFA from other technologies to support profiling adoption risk identification for organizations that are adopting agile methods. The second post continued the discussion with a more in-depth dive into organizational climate, one of the six RFA categories.

Adapting the Readiness & Fit Analysis to Agile

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. It is included there because adopting new practices like those found in SEI's CMMI models involves adoption risk, as do 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. As part of the SEI's research in the adoption of agile methods in U.S. DoD government settings, we have adapted the RFA profiling technique to accommodate typical factors used in RFA and other factors more uniquely associated with the DoD government acquisition environment. 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 this 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 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're 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. As a reminder, an example attribute from the business and acquisition category is stated as follows:

Oversight mechanisms are aligned with agile principles.

Comments: Oversight is an aspect of acquisition that can either support or disable an agile project. So alignment of the oversight with agile principles provides less risk of oversight being counterproductive. If you were evaluating your organization's "fit" with this attribute, you would think about how oversight occurs currently in comparison to the twelve agile principles found with the Agile Manifesto.

From the title of this method - Readiness and Fit - it would be easy to assume that the only time you could productively use this method would be in the early stages of adoption, when you're trying to decide if you're ready to adopt and if the practices you're considering are a fit for your organization. In practice, however, we have used models like this at multiple points in the adoption of a new technology or method.

Certainty regarding readiness for agile adoption changes 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 our adoption success. Later in the adoption process, performing an RFA highlights adoption risk areas overlooked during early phases of adoption and areas where we now have more data to help guide us in developing adoption risk mitigation strategies.

For example, we may not initially understand that our approach to cost estimation in a larger organization doesn't easily accommodate certain agile practices, such as relative estimation. After we have been through one or two pilots, we are likely to understand the effect relative estimation has on our results, and we can develop strategies to help connect the agile estimation practices to those of the larger program. The key point here is to be prepared to apply RFA principles and techniques at multiple points in your adoption journey.

Organizational Climate

The remainder of this post is dedicated to completing our discussion that we began in the second post on organizational climate, the most expansive category of the RFA that includes culture, value, and working principles. Organizational climate includes the internal operations and culture of an entity, which are extremely important in determining its readiness for agile adoption.

Organizational culture is one of hardest RFA categories to assess when considering agile adoption readiness. Culture encompasses assumptions about appropriate or inappropriate behavior and the values held by the members of an organization. For example, in DoD organizations, culture is typically plan-driven and hierarchical, with strict command-and-control structures for communication and leadership. Organizations that are "fit" to adopt agile generally need to be empirical, collaborative, self-organizing, and cross-functional.

The following list completes our subset of factors within the Organizational Climate category that are considered when performing an RFA. The second post in this series highlighted factors including cascading sponsorship, aligned incentives, external policy support, sponsors who understand agile, a reward system that supports agile, and senior support for agile. Below we explore the remaining factors, including user and customer focus, positive change history, requirements change posture, an agile-supportive environment, a trusting environment, and a "fail early, fail fast, and learn" philosophy.

User and customer focus. Organization supports early and frequent delivery of potentially shippable software to customers.

The first principle associated with the agile manifesto states, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." Most traditional government programs deliver software at the end of the development lifecycle (i.e., the "big bang" approach to system integration). The government organizational structure and culture are conducive to this one-time delivery. Structural changes will be required to support the iterative nature of agile/lean development which requires more frequent user interaction. The changes may impact the organization, staffing, and interactions with organizations such as Information Assurance and Operational Test. Above all, the projects' structures and support mechanisms must account for the user interaction needed to frequently deliver potentially-shippable software; it should also account for the internal oversight mechanisms needed to support frequent, evolving deliveries.

Positive change history. Organization's change history for introducing new engineering and management approaches is recently positive.

Change is hard. Some organizations are better suited to make operational changes than others. Organizations that have successfully implemented a new expense reporting system, or adopted new analysis practices will more likely succeed in their initial attempts at implementing agile or lean methods. These organizations will have well-established mechanisms for supporting new practices. In cases where recent change experiences have been negative, the adoption strategy can be changed to provide small, positive experiences prior to the larger changes as a way of overcoming the negative history and its effects.

Environment that embraces requirements changes. Organization provides mechanisms that support accommodation of inevitably changing requirements.

The second principle of the agile manifesto states, "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." In the DoD environment, the Joint Capabilities Integration Development System (JCIDS) process requires that top-level requirements be fully specified locked down early in the acquisition process, which makes these requirements extremely hard to change. The agile concept of welcoming change is antithetical to this process. The adoption and full realization of the benefits from the agile methods will therefore be hard to achieve if accommodations are not explicitly made within the project's acquisition environment to allow for changing requirements. A typical solution to this dilemma is to ensure that the early requirements are at a high enough level that the customer organization can make needed changes at the detailed level as their understanding of the specific requirements matures.

Agile-supportive environment. Physical and social environments needed for agile team success are provided by the organization.

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." The sixth principle states, "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." Agile environments typically house cross-functional teams in common areas where the teams can work together and have regular face-to-face conversations. Even if the teams are physically separated, modern communications and social media methods (such as video-teleconferences, instant messaging chats, and Skype) are used to promote continuous discussion and sharing of information. Designating a "team space" for physically co-located teams to work with appropriate network and IT environment access can be as simple as dedicating a conference room to the team for the duration of the project. We have seen some distributed teams establish a continuously "open" chat room where team members can talk about their work.

Trusting environment. Organization supports a climate of trust between acquirers and developers.

Agile environments are created around 12 core principles. These principles focus on fostering trust within agile teams and between teams and their customers and users. The DoD acquisition environment is built upon oversight and "trust but verify." In many instances, we have seen relationships between the acquirers and the developers in traditional acquisitions that are adversarial. A climate of trust enables agile methods to achieve their fullest potential. Trust is usually built via shared experiences where all parties feel respected and accepted. A joint workshop or event that focuses on the work, but provides opportunities for working together across organizational boundaries, is often a first step in that journey.

Fail/learn fast. A "fail early, fail fast, and learn" philosophy is supported by the organization in which development occurs.

The 10th principle of the agile manifesto states, "Simplicity--the art of maximizing the amount of work not done--is essential." This principle helps teams avoid unnecessary, non-productive work. Simplicity is the art of employing just enough documentation, process, oversight, and work to evolve the needed product. DoD acquisition processes--while tailorable--do not innately support the idea of "just enough," which is a skill and a mindset that must be fostered, encouraged, and adopted across the lifecycle. In addition, agile teams deliver software frequently; frequent delivery helps them learn what works and what doesn't, and adjust accordingly.

Looking Ahead

While Organizational Climate involves many factors when considering agile adoption, these factors often need the most attention when determining readiness and fitness for agile adoption. 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 another important RFA category: project and customer environment. This category deals with the interactions among the development team and the interactions between the development team and its customer and users.

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.