A number of years ago we predicted that by 2007 or 2008 agile adoption would be on the rise and that the agile community would be in need for a structured approach to help it with its agile adoption efforts. As a result, we invested time, effort, and money to develop an efficient and effective approach to guide and assist those who want to adopt agile practices. Last month we started to see our prediction become a reality when the tentative program for the Agile 2007 conference was posted online. The program contained more than ten sessions focusing solely on the issue of agile adoption, either implicitly or explicitly. 

This indicates, at least to us, that more and more organizations want to know how to adopt agile practices. Well, if your organization is starting the journey of adopting agile practices, we are certain that the Agile Adoption Framework will help you. The Agile Adoption Framework is a model that provides organizations aspiring to adopt agile practices with structured guidance and assistance. The framework addresses some of the common challenges of agile adoption using a unique and efficient approach.

In Part 1 of this article, Disciplined Approach to Adopting Agile: Adoption Framework, we presented the first component of the Agile Adoption Framework, the Sidky Agile Measurement Index (SAMI) and its Agile levels, principles, practices, concepts, and indicators. The SAMI is an integral part of the framework because it provides an approach to measure the agile potential of a project or organization.

In this Part 2 we present the second component of the Agile Adoption Framework: the 4-Stage Process. As depicted in Figure 1, the {sidebar id=1} four stages work together to help the assessor (agile consultant or coach) determine if (or when) an organization is ready to move toward agility, or, in other words, make the go/no-go decision. The 4-Stage Process also assists him or her in the process of identifying which agile practices the organization should adopt. The next sections explain in detail each stage of the 4-Stage process.

Stage 1: Identifying Discontinuing Factors
Stage 1 provides an assessment process to help identify key factors which could prevent the successful adoption of agile practices. These are called discontinuing factors and can vary from one organization to another. Typically, they pertain to an organization's resources including money, time, and effort, as well as the support of its leadership. The three discontinuing factors identified by the Agile Adoption Framework are:

• Inappropriate Need for Agility: This refers to situations where, from a business or software development perspective, adopting agility does not add any value.

• Lack of Sufficient Funds: Whenfunds are unavailable or insufficient to support the agile adoption effort, then an adoption process is not feasible.

• Absence of Executive Support: If committed support from executive sponsors is absent, then effective and substantial change in the organization is unlikely to occur.

When an organization demonstrates any of these discontinuing factors, it is unprepared to move towards agility and should suspend the adoption process until the environment is more supportive.
Once Stage 1 indicates that the organization is ready to move towards agility, the journey of introducing agile practices into the development process begins. This involves determining which agile practices and concepts are most suitable for the organization to adopt. Actually, to be more realistic, the Agile Adoption Framework first determines the agile practices that a particular project can adopt, not the whole organization. The framework is based on the fundamental belief that each project in an organization can adopt a different degree of agility based on its context. Therefore, the last three stages provide guidelines for identifying the agile practices suitable for a single project.

Stage 2: Project Level Assessment
Stage 2 is the first stage of the adoption process that utilizes the SAMI. The objective of this stage is to identify the highest level of agility a project can achieve. This is called the target level and is one of the five agile levels of the SAMI. In theory, all projects should aspire to reach the highest level of agility possible. However, the reality is that circumstances, often outside of the organization's control, surround each project. These circumstances become constraining factors if they adversely affect the organization's ability to adopt an agile practice. Thus, constraining factors limit the level of agility to which a project aspires.

For example, the "customer's collaboration commitment" could be a constraining factor if the customer is not willing to commit to a certain level of collaboration with the development team. This factor is considered to be constraining because adopting certain agile practices depends on it [customer's collaboration commitment] and changing it is outside the organization's control.
Because achieving the highest level of agility depends on project circumstances outside of an organization's control, the first step in Project Level Assessment is to identify those agile practices and concepts that rely upon those circumstances for their successful adoption. These agile practices are known as limiting agile practices, because if the project characteristics needed to support these practices are not present, the inability to adopt the practice constrains or limits the level of agility attainable by the project. In Table 1, which illustrates the SAMI, the limiting agile practices are underlined.

The assessment process defined by Stage 2 focuses on determining the target level of agility for a project. More specifically, it examines only those factors associated with the limiting agile practice, and measures the extent to which they are present. The assessment is conducted using the indicators associated with each limiting agile practice (indicators were discussed in Part 1 of this article). The process starts by examining the limiting practices at Agile Level 1, and then moves upward on the scale. Once factors needed for the adoption of a limiting practice are found to be missing, the assessment process stops, and the highest level of agility attainable for the project is set to be the level at which that limiting practice is found.

For example, a limiting agile practice at Level 3 is frequent face-to-face communication. A factor that is needed for frequent face-to-face communication is for the team to be geographically close to each other, or at least have the technology to simulate that. Assume that the project and organization have no say in changing this characteristic (team proximity), because it is outside of their control. If the project level assessment determines that the factor (near team proximity or the technology to simulate it) is missing for this project, then the highest level of agility for this project will be the same level of agility in which this agile practice is found (which is Level 3 in this case). This example is not discussing the issue of global/offshore Agile development, it is simply illustrating an example of project level assessment. Having distributed teams does not eliminate agility but it simply may restrict the "level of agility" the project operates at.

It is also noteworthy to remind the reader that the Sidky Agile Measurement Index (SAMI) is tailorable and hence the location of the practices within the SAMI can be changed according to some guidelines (tailorability of the SAMI is discussed in Part 1 of this article).

In summary, the target level of agility is determined at the point when the assessment process discovers that one of the project characteristics needed to adopt a limiting agile practice or concept is missing, and neither the project nor organization can do anything to influence or change this circumstance. Figure 2 is a conceptual illustration of this stage. After the target agile level for the project is identified, the next step in the journey is to conduct an organizational readiness assessment to determine the set of agile practices (for the project) that can realistically be adopted.

Stage 3: Organizational Readiness Assessment
Identifying the target level for a project does not necessarily mean that the organization is ready to allow the project to reach that level. To determine the extent to which that target level can be achieved, the organization must be assessed to determine whether it is ready to adopt each of the agile practices and concepts associated up to, and including, the target level. Investing time and effort in this type of pre-adoption assessment of each agile practice increases the probability of success for the overall transition to agility, because it significantly reduces the risks associated with the agile adoption process. Even though this may seem as a cumbersome process, it is not. Organizational assessments can be easily automated and hence conducted very easily and quickly.

Similar to Stage 2, Stage 3 of the process also relies on the SAMI. The indicators play a critical role in determining the extent to which the target level can be achieved. To save time and money during this assessment stage, instead of assessing how ready the organization is relative to adopting the practices in all five agile levels, only those within the target agile level and below are used. The assessor uses the set of indicators (questions) associated with the agile practices to measure the extent to which each of these organizational characteristics are present. Figure 3 is a visual representation of Stage 3.
Each of these organizational characteristics is assessed using a number of different questions. Depending on the question, a manager or developer within the organization, or the assessor himself or herself answers it. The SAMI defines approximately 300 indicators to measure the various organizational characteristics related to agile practices and concepts.

The result of the organizational assessment stage is a table that depicts the extent to which each organizational characteristic is achieved (see Table 2). This format for displaying results is beneficial to executives and decision makers as it draws attention to the characteristics of the organization that might cause the adoption of a practice to fail.
Similar to a project level assessment, determining the highest agile level an organization is capable of achieving depends on the organization's readiness to adopt the practices in that agile level. If the organizational characteristics needed for to successfully adopt a practice are absent, the organization is not ready to adopt that practice.

Stage 4: Reconciliation
Following the organizational readiness assessment, the agile level achievable by the organization is known. Prior to that, Stage 2 had identified the agile level that the project aspires to adopt. The final step, reconciliation, is necessary to determine the agile practices the project will adopt. During this phase the differences between the target level and the organization's readiness are resolved to determine the final set of agile practices that will be adopted. When organization readiness level (from Stage 3) is less than the project target level (from Stage 2), reconciliation is necessary. The framework provides two options for reconciling this situation (see Figure 4).

Option 1: The first option relies on how ready and willing the organization is for changes and improvements. The results of the organizational assessment have identified exactly which characteristics are hindering the organization from reaching higher levels of agility (i.e., the project's target level). If changing any of these characteristics is within the control of the organization, then the organization can undertake the necessary steps to improve these characteristics. Once all the recommended changes have been successfully made, the organization can support agile practices at the project's target level.

Option 2:The second option is suitable for organizations that are not willing to invest time, effort, or money towards change, and only want to adopt those agile practices that are within their current capacity. In that case, it is recommended to adopt only the agile practices for which the organization is ready. The obvious downside to this approach is that the project is restricted to operating at a lower level of agility than its potential.

This reconciliation stage helps the organization realistically identify the agile practices it can adopt. At the same time, if the organization is able and willing to improve, then this stage guides it as to where the improvements need to occur so that an individual project can operate at its full agile potential. Moreover, by utilizing this approach, the organization prepares itself sufficiently before starting the process of introducing agile practices into the development process.

Conclusion
The Agile Adoption Framework provides organizations with a structured and repeatable approach to guide and assist them in the move toward agility. The framework is independent of any one particular agile method or style, there are no restrictions on using XP or SCRUM or any other agile practices within the framework. Moreover, the framework has two levels of assessment: one at the project level and another on an organizational level. Hence, it accommodates the uniqueness of each project, and at the same time, recognizes that each project is surrounded by, and is part of, an overall organization that must be ready to adopt the requisite agile practices. We view the Agile Adoption Framework as an initial contribution towards answering the complex question of how to adopt agile practices. While we recognize that the framework has yet to reach its full potential, we are encouraged by the comments given to the Agile Adoption Framework from members of the agile community.

About the authors
Ahmed Sidky is a senior agile consultant with Tangible Software. He graduated as Valedictorian with a Bachelor's degree in Computer Science from the Modern Science and Arts (MSA) University in Cairo, Egypt. While working as an Internet Solution Developer for one of the leading corporations in Egypt, he received the award for the Best Creative Solution for that year. With his research focused on Requirements Engineering, he earned a Masters degree in Software Engineering from Virginia Tech. Ahmed's research interests then moved towards Agile Software Development Methodologies. His latest research is a process framework for the adoption of agile practices known as the Agile Adoption Framework.

James D. Arthur is an Associate Professor of Computer Science at Virginia Tech. He received B.S and M.A. degrees in Mathematics from the University of North Carolina at Greensboro, and M.S. and Ph.D. degrees in Computer Science from Purdue University. His research interests include Software Engineering (Methods and Methodologies supporting Software Quality Assessment and Processes), Parallel Computation, and User Support Environments.