Disciplined Approach to Adopting Agile: Adoption Framework

Part 1
Over the past few years organizations have asked the agile community "Why should we adopt agile practices?" Today, however, they are turning to the agile community, with a different question: "How do we proceed with adopting agile practices?"; Unfortunately, there is no structured approach (at least that is published in the public domain) for agile adoption. The absence of guidance and assistance to organizations pursuing agility is the main problem addressed by this article.

Over the past few years organizations have asked the agile community "Why should we adopt agile practices?" Today, however, they are turning to the agile community, with a different question: "How do we proceed with adopting agile practices?"; Unfortunately, there is no structured approach (at least that is published in the public domain) for agile adoption. The absence of guidance and assistance to organizations pursuing agility is the main problem addressed by this article.

The Agile Adoption Framework, introduced in a two-part article, is an attempt to provide a structured and repeatable approach to guide and assist agile adoption efforts. The Agile Adoption Framework provides an essential ingredient for successfully adopting agile practices, but this alone is not enough. Some element of interpreting the measures and guidance throughout the four stages of the framework is also important- perhaps via an experienced agile coach or an in-house employee with sufficient training on agile methods and the use of the framework.

Figure 1. The Agile Adoption Framework

The Agile Adoption Framework has two main components: (1) a measurement index for estimating agile potential, and (2) a 4-Stage process that employs the measurement index in determining which, and to what extent, agile practices can be introduced into the organization. Figure 1 illustrates the different components of the framework and the relationships among them.
Part 1 of this article presents the structure and details of the Sidky Agile Measurement Index (SAMI). Each of the four stages in the process will be presented in detail in Part 2 of the article.

The Sidky Agile Measurement Index
One of the concerns organizations have when seeking to adopt agile practices is determining how agile they can become. The agile potential (i.e., the degree to which that entity can adopt agile practices) of projects and organizations is influenced by the circumstances {sidebar id=1} surrounding them. To determine the agile potential, the coach (or the one conducting the assessment) needs use a measurement index or scale that can assess the agility of an entity. The Agile Adoption Framework uses the SAMI to determine the agile potential of projects and organizations. The SAMI is an agile measurement index that is composed of four components:

  1. Agile Levels consist of a set of agile practices that are related and, when adopted collectively, would make significant improvements in the software development process, thereby leading to the realization of a core value of agility.
  2. Agile Principles are guidelines that need to be employed to ensure that the development process is agile.
  3. Agile Practices and Concepts are the concrete activities and practical techniques used to develop and manage software projects in a manner consistent with the agile principles.
  4. Indicators are questions the assessor uses to assess certain characteristics of an organization or project, such as its people, culture, and environment, in order to determine assess the readiness of the organization or project to adopt an agile practice.

Each of component of the SAMI is discussed below.

Agile Levels
Agile levels, as depicted in Figure 2, are considered the units of the measurement scale as they enumerate the different possible degrees of agility for a project or organization. The agile potential of a project or organization is expressed in terms of the highest agile level it can achieve. The attainment of a particular level symbolizes that the project or organization has realized and embraced the essential element needed to establish an agile development process. For example, when the elements inherent to enhancing communication and collaboration are embodied within the development process, then the Agile Level 1 (Collaborative) is attained. However, before one can except to move to Level 2 status, all practices associated with Agile Level 1 must be achieved (or achievable).




Figure 2. Components of the SAMI (Indicators are not shown)

 The 5 Levels of Agility are designed to represent the core qualities of the Agile Manifesto rather than the qualities related to any particular agile method. After careful analysis of the manifesto, five essential agile qualities have been identified. Those qualities comprise the 5 Levels of Agility that are used by the SAMI:

  • Level 1: Collaborative. This level denotes the fostering of communication and collaboration between all stakeholders. Collaboration is the foundation of agile software development.
  • Level 2: Evolutionary. Evolutionary development is the early and continuous delivery of software. It, too, is fundamental because every agile method assumes its presence.
  • Level 3: Effective. The focus in this level is to increase efficiency of the development process by adopting engineering practices that will lead to the development of high quality working software. This is needed to prepare the development process for the next level where it can respond to constant change without jeopardizing the software system being developed.
  • Level 4: Adaptive. This level constitutes establishing the agile quality of responding to change in the process. Defining and responding to multiple levels of feedback is essential in this level.
  • Level 5: Encompassing. Agility is essentially a culture, and it is important to have an environment that is reflective and supportive of the agile nature of the software development process. This level concentrates on establishing an all-encompassing environment to sustain and foster agility throughout an organization.

Each of the agile levels is composed of a set of agile practices that introduce and sustain the agile quality pertinent to that level. The selection of agile practices and concepts assigned to each agile level is guided by the second component of the measurement index, agile principles.

Agile Principles
Agile principles are the essential characteristics that must be reflected in a process before it is considered Agile. For example, two key agile principles are human centric, which refers to the reliance on people and the interaction between them, and technical excellence, which implies the use of procedures that produce and maintain the highest quality of code possible. The Agile Manifesto outlines 12 principles that characterize agile development processes. After careful grouping and summarization, five agile principles emerged that capture the essence of the 12. These five principles guide the refinement or tailoring of the SAMI:

    • Embrace change to deliver customer value.
    • Plan and deliver software frequently.
    • Human centric.
    • Technical excellence.
    • Customer collaboration.

In effect, agile principles are used to ensure that the agile levels embody the essential characteristics of agility. Figure 2 illustrates the relationship between agile levels and agile principles. Each agile level should contain agile practices associated with most, if not all, of the agile principles. The principle reflects the approach that the agile practice uses to promote the agile quality pertinent to a level. For example, all the practices in Level 3 (Effective) are promoting the agile objective of developing high quality, working software in an efficient an effective manner. How that objective is achieved though, is determined by the practices associated with agile principles spanning each level. Along the same lines, practices associated with the technical excellence principle will promote its agile objective by focusing on enhancing the technical aspect of the process, while practices associated with the human centric principle promote enhancing the human aspect of the process.

The real essence of the SAMI, however, is in the agile practices it enunciates. The next section presents the third component of the 5 Levels of Agility - the agile practices.

Agile Practices
Agilepractices are concrete activities and practical techniques that are used to develop and manage software projects in a manner consistent with the agile principles. For example, paired programming, user stories, and collaborative planning are all agile practices. Since the agile levels are composed of agile practices (organized along the line of agile principles - see Figure 2), they are considered the basic building block of the SAMI. The attainment of an agile level is achieved only when the agile practices associated with it are adopted.

After surveying the agile methods currently used in the industry, forty distinct agile practices were selected to populate the SAMI. These practices, arranged along the lines of the agile levels and principles are illustrated in Table 1.

Table 1. The 5 Levels of Agility populated with Agile Practices and Concepts


A set of indicators, or questions, must accompany eachagile practice or concept in the measurement index. The agile coach uses these indicators (or questions) to measure the extent to which the organization is ready to adopt an agile practice or concept. Each indicator is designed to measure a particular organizational characteristic necessary for the successful adoption of the agile practice the indicator is related to. Depending on the question, a manager, developer, or the agile coach is designated to answer it, either subjectively or objectively.

For example, assume the coach wants to determine the extent to which the organization is ready to adopt coding standards (Level 1, Technical Excellence). In this respect, two organizational characteristics that need to be assessed are: (1) to what extent do the developers understand the benefits behind coding standards, and (2) how willing are they to conform to coding standards. Several indicators (or questions) are used to assess each of these characteristics. For example, to assess the second (willingness), the assessor might ask the developers to what extent would they abide by coding standards even when under a time constraint.

The SAMI contains approximately 300 different readiness indicators for the 40 agile practices. The SAMI shown in Table 1 is one instance of the agile measurement index. Can there, however, be alternate instances? Yes, the next section discusses briefly the tailorability of the SAMI.

Tailorability of the SAMI
The SAMI, along with all its levels, practices and indicators, was presented to members of the agile community during the end of 2006. The agile coaches and consultants: AlistairCockburn [1], Mike Cohn [2], Bill Wake [3], and Sanjiv Augustine [4], and others, suggested a reorganization of the agile practices based on experiential successes. For example, Cohn has suggested that user stories be introduced in the first level of agility, because, from his experience, they enhance collaboration and communication between the stakeholders with regard to requirements.

Others suggested that pair programming be in the first level because it helps to establish collaboration within teams. This inability to reach a consensus on the position of agile practice emphasizes an important factor in providing guidance in an agile adoption effort: the adherence to agile principles when establishing the levels is paramount, not the positions of the actual practices within the model.

The intention behind the levels of agility is to provide a framework to guide the adoption process, not to dictate it. We actually encourage coaches to revisit the positions of the practices after each adoption effort to tune them according to their teams' experiences. After all, agile development promotes learning, reflecting, and tuning the process to reflect what actually works; agile adoption is no different.

The SAMI Beyond the Agile Adoption Framework
While the Agile Adoption Framework uses the SAMI mainly to identify the agile potential of a project, in reality the SAMI has a number of other beneficial uses.

First, the SAMI can be considered a roadmap for agile adoption efforts. The level-based structure of the SAMI provides organizations or individuals with little or no knowledge of agile adoption with substantial guidance on how to start and proceed with agile adoption efforts.

Secondly, the SAMI can be used to assess an organization's current state of agility, irrelevant of whether they are undergoing agile adoption or not. This can be achieved by using a set of adherence indicators instead of the current set of readiness indicators associated with each agile practice. In that case, the organization's level of agility is based on its degree of adherence to the agile practices within each level.

The third form of use for the SAMI is to identify a target agile level for a project aspiring to use agile practices. The 4-Stage Process component of the Agile Adoption Framework utilizes the SAMI for this particular purpose.

The focus of this article is not to describe how the different uses of the SAMI but to highlight how the Agile Adoption Framework uses the SAMI to guides agile adoption efforts. Therefore, only the third use of the SAMI (identifying the target agile level of a project) will be presented. Make sure to read Part 2 of this article next month, to discover how exactly the 4-Stage Process within the Agile Adoption Framework uses the SAMI to guide agile adoption initiatives.

See Part 2 - Disciplined Approach to Adopting Agile: Four-Step Process 

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 and he is completing his doctorate in May 2007 in that field. 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 (VPIamp;SU). He received B.S and M.A. degrees in Mathematics from the University of North Carolina at Greensboro in 1972 and 1973, and M.S. and Ph.D. degrees in Computer Science from Purdue University in 1981 and 1983. His research interests include Software Engineering (Methods and Methodologies supporting Software Quality Assessment and IVamp;V Processes), Parallel Computation, and User Support Environments. Dr. Arthur is the author of over 30 papers on software engineering, software quality assessment, IVamp;V, and user/machine interaction. He has served as: participating member of IEEE Working Group on Reference Models for Vamp;V Methods; Chair of Education Panel for National Software Council Workshop; Guest Editor for Annals of Software Engineering special volume on Process and Product Quality Measurement; and Principal Investigator or Investigator on 14 externally funded research projects totaling in excess of $1.4 million. Dr. Arthur is a member of Pi Mu Epsilon (Math Honor Society), Upsilon Pi Epsilon (Computer Science Honor Society), Golden Key National Honor Society, Sigma Xi (National Research Society), ACM, and the IEEE Computer Society.

[1] Alistair Cockburn, http://alistair.cockburn.us/

[2] Mike Cohn, Mountain Goat Software, http://www.mountaingoatsoftware.com

[3] Bill Wake, http://xp123.com/wwake/

[4] Sanjiv Augustine, CC Pace, http://www.sanjivaugustine.com/

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.