The adoption of new practices, such as agile or any new practice for that matter, is a task that is best undertaken with both eyes open. There are often disconnects between the adopting organization’s current practice and culture and the new practices being adopted. This posting is the second installment in a series on Readiness & Fit Analysis (RFA), which is a model and method for understanding risks when contemplating or embarking on the adoption of new practices, in this case agile methods. The RFA method helps organizations understand the barriers and enablers to successful adoption that are present when an analysis is performed. The first post in this series outlined the principles of RFA and described the Acquisition Support Program’s work in extending RFA to support profiling and adoption risk identification to organizations that are adopting agile methods. This blog post continues the discussion with a more in-depth dive into one more of the six RFA categories that we have identified.
In our work with the Department of Defense (DoD), we often encounter organizations that have been asked by their government program office to adopt agile methods. These are organizations that have traditionally performed an engineering “V” lifecycle and are accustomed to being managed via a series of document-centric technical reviews, which focus on the evolution of the documents that describe the requirements and design of the system rather than focusing on 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. Hence, they struggle to adopt agile practices.
For example, contractor personnel often aren’t accustomed to working shoulder-to-shoulder with government counterparts, and the transparency of daily task management is uncomfortable. After a short period of time, programs often revert back to a more traditional approach, even though end users gave positive feedback about what was produced during the timeframe that agile methods were used. This common scenario highlights a disconnect in business strategy, values, and management style that often occurs in organizations trying to adopt new practices. These aren’t the only disconnects, but they are representative of what we often see when working with DoD or other regulated organizations trying to adopt agile methods.
Adapting the Readiness Fit Analysis (RFA) 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. As part of the SEI’s research in the adoption of agile methods in U.S. DoD settings, we have adapted the RFA profiling technique to accommodate typical factors used in RFA and other factors more uniquely associated with the DoD acquisition environment.
To date, we have characterized six categories to profile for readiness and fit:
- business and acquisition (details discussed in the first post in this series)
- organizational climate
- system attributes
- project and customer environment
- technology environment
Determining Readiness & Fit
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 attribute of business and acquisition is stated as follows:
Oversight mechanisms are aligned with agile principles.
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.
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. Actually, we have used models like this at multiple points in the adoption of a new technology or practice.
Your certainty regarding the state of the organization in relation to factors represented in the RFA changes from early use of the method (before initial pilots) to later use (after you’ve run two or three releases using an agile method). Your certainty also changes with respect to the importance of a specific factor to your organization’s success.
At the beginning of an agile adoption project, we are often uncertain about the state of the organization 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 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. So don’t hesitate to apply RFA principles and techniques at multiple points in your adoption journey.
This blog entry focuses on a portion of a single RFA category: Organizational Climate. This category is one of the longer categories in the set, because misfits in organizational climate— including culture, values, and working principles—are particularly troublesome areas for many organizations pursuing agile adoption.
This category covers the internal operations and culture of an organization, which are extremely important in determining fit. The alignment of the organization’s inherent operations to agile concepts and principles will help determine the ease or difficulty of the transition.
The organization’s culture is one of most difficult issues to assess for agile adoption readiness. Culture encompasses assumptions about appropriate or inappropriate behavior and values ingrained in the members of an organization. For instance, in DoD organizations the culture is typically plan-driven and hierarchical, with strict command-and-control structures for communication and leadership. An organization adopting agile methods is generally more empirical, collaborative, self-organizing, and cross-functional.
The following list specifies a subset of the factors within the Organizational Climate category that must be considered when an organization performs an RFA. This category includes leadership, sponsorship, incentives, values, structures, and organizational-change history. We’ll deal first with leadership, sponsorship, and incentives, which can either be aligned to an agile perspective, or misaligned, which is often a source of behaviors that may appear as resistance to the new practices.
Understanding misaligned factors is important in addressing their symptoms proactively. The list includes a tag (a short title that summarizes the statement) and a statement that provides a condition or behavior that would be expected in an organization successfully using engineering and management methods consistent with agile principles as published in the Agile Manifesto. When applying an RFA, you look at the statement, and then consider the “fit” of that statement to your own organization’s behaviors or attitudes.
Cascading sponsorship. Sponsor support for the use of agile or lean methods use is explicit and cascading. In particular, the sponsorship doesn’t just emanate from the program manager, it cascades throughout the acquisition chain.
In most organizations, a move to agile methods involves new behaviors and different values. This paradigm is a major change in how an organization operates, and it will affect the overall climate. For DoD organizations, the entire acquisition eco-system includes not just the program but outside organizations, such as Certification and Accreditation and Operational Test & Evaluation. Due to policies and regulations, it can be hard to include these parts of the acquisition chain when adopting agile or lean methods. Cascading sponsorship helps alleviate these problems by having sponsors in multiple places within the organization who can model the new values and behaviors, instilling confidence in the people who are actively trying to adopt the new practices.
Aligned incentives. Incentives among stakeholders are aligned to reflect agile principles.
The fifth agile principle related to 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.” Part of this environment and support is the incentive to work in an agile environment. Most traditional organizations have incentives aligned to individuals but not many incentives for teams. For agile or lean environments, the incentives must be aligned to enable the team to succeed, not to make an individual hero.
External policy support. Adherence to agile or lean principles is supported by external policies.
For example, the National Defense Authorization Act (NDAA) Section 804 promotes an iterative, incremental style of acquiring information systems that includes software-intensive systems. This legislation aids in the adoption of agile/lean methods and provides guidance in policy and regulation. In addition, Section 933 provides a strategy for acquisition and oversight of DoD cyber warfare capabilities, which also points back to section 804 of the 2010 NDAA. These are high-level examples of policy support of agile principles. Within a particular organization, however, there may be an opportunity for guidance that can push individuals and groups into adopting agile methods. For example, the CIO of a particular agency may mandate adoption of agile principles for their organizations.
Caution: Using a policy or mandate to FORCE adherence to agile principles is not productive for healthy adoption of new practices. Putting policies in place too early, before the appropriate transition mechanisms are in place, often leads to malicious compliance. Malicious compliance occurs when individuals adhere to the letter of the law so rigidly that the practices can be adopted in an unproductive way.
Sponsors understand agile. Sponsors understand and support the difference in roles and business rhythm when using agile approaches.
The roles and responsibilities in a traditional acquisition are well documented in DoD policies, regulations, and training documents; in an agile environment they are different and not as easily understood. Sponsors must understand the four tenets of the Agile Manifesto and the 12 underlying principles to enable the necessary business rhythm for an agile development effort. They also must understand the chosen agile practices well enough to understand the role and responsibility implications of the particular practices that have been selected.
Reward system supports agile. The organizational reward system supports the team-based reward focus of agile methods.
The reward system is closely related to the incentives used on a program. As stated above, agile and lean organizations focus their rewards on team behavior, whereas traditional organizations reward individual behavior. Within the DoD environment, the reward system (via the performance-management system) is structured and not easily changed. This structure may actually interfere with the support and reinforcement of a more agile environment. There are ancillary reward system mechanisms, however, such as public praise, high evaluations, access to training, and certificate programs that may supplement individual-focused performance rewards. One of the key aspects of a successful reward system is understanding the kinds of rewards that individuals actually value (many teams would value an extra day off more than a gift certificate, for example).
Senior support for agile. Senior stakeholders openly and explicitly support the use of agile or lean methods in the program.
Successful agile implementations have consistently had a champion. The champion may or may not be a senior stakeholder, but it is someone who has the respect of adopters and the support of senior leadership in the organization. This status will help protect fledgling agile projects from being derailed by those who do not understand the new methods or are uncomfortable with change. Open and explicit support by the senior stakeholders also means that old behaviors are no longer rewarded. This factor is often one of the hardest for senior stakeholders to consistently practice when sponsoring change.
As you can see, the list of factors in the Organizational Climate category is lengthy, but these factors often need the most attention in promoting a successful adoption of agile methods and principles. As stated at the beginning, however, this is just one category out of six, and only the first five factors within that category. Each category offers insight into the adoption risks that a particular organization will face when adoption agile methods. Identifying these risks is an important first step toward planning and executing mitigation strategies to address them.
This series of posts describes how RFA has been used for multiple technologies and sets of practices (most notably CMMI) to help organizations in the DoD and other regulated environments mitigate agile adoption risks. In the first post in this series, we addressed Business & Acquisition, and in this post we introduced Organizational Climate. The next post in will address the remaining factors in Organizational Climate. Subsequent posts will address one or more of the remaining RFA categories: System Attributes, Technology Environment, Project and Customer Environment, and Practices.
A 2011 SEI technical note, Agile Methods: Selected DoD Management and Acquisition Concerns, outlines many of the organization climate issues that arise in agile adoption in the DoD. To download the report, please visit