Agile Fluency - THE Model for Agile Development?

The Dilemma of Maturity Models

Even the organizations that have embarked on their agile journey and that we have had the opportunity to accompany have tried to measure agility, and in very different ways. It is fair to ask how agility should be measured. By practices? By collaboration in a team and the way conflicts are resolved? By arbitrarily chosen goals set by the company? Or by whether a team presents its results to a PO, stakeholder, or directly to the customer during a review?

To know where they stand, some companies turn to maturity models. Most models for measuring agile maturity assume that there is an ideal state in which the organization has completely internalized a certain characteristic. Conversely, organizations that are not yet at the highest level could be considered somewhat “underdeveloped” or deficient. However, the goal I want to achieve with agility is dependent on the context in which I operate as a company and therefore cannot be generalized.

Yet other valid questions remain unanswered: “How long will it take?” or “How much will it cost?”, for example from the management level. Why do I mention management here? Because no team can become agile without management support. Their support is indispensable. Once a goal is set, the company wants to know how success is measured and what the path there will cost.

Agile Fluency

The “Agile Fluency Model” developed by Diana Larsen and James Shore in 2012 provides an answer to these challenges. In this blog post, we will explore whether the Agile Fluency Model presents itself as an alternative for measuring and achieving agile maturity.

The “Agile Fluency Model” should be a good tool, at least at the team level, to determine where a team is on their agile journey. However, the authors of the model emphasize that the model should in no way be used to measure agile maturity. Diana Larsen and James Shore’s model is intended more as a guide and framework than an assessment tool. It provides a structure for understanding and supporting a team’s journey through different levels of agility. The focus is on how well a team implements the principles and practices of agile methods in its daily work. The model comprises four zones reflecting the evolutionary progress of an Agile journey:

• Focusing on Value,
• Delivering Value,
• Optimizing Value,
• Optimizing for System.

Unlike other models that examine organizational agility, the “Agile Fluency Model” specifically focuses on the team level. It recognizes the reality that teams are the fundamental unit of work and the key driver of agile transformations.

The authors describe each of the four stages and provide them with expected outcomes, costs, and the time it takes to reach the desired level of fluency. The word “fluency” is intentionally used here, as the authors believe that a certain level is only achieved when the team has internalized the habits and can apply them in truly every situation, i.e., even under stress, and compare this to learning (hence “fluency”) a language. The model recognizes that teams evolve gradually and achieve “fluency” in agile practices over time. It provides a kind of roadmap for teams to progress from one stage to the next, enabling steady development.

The model also recognizes that teams may have different goals, priorities, and constraints. It allows teams to adapt their practices based on their specific circumstances and gives them the flexibility to choose the right agile practices that meet their needs. For this reason, Larsen and Shore emphasize that not every team should strive for the highest level in their model. As mentioned at the beginning of this post: every product and every organization is different, and precisely for this reason, it is pointless to assume that every team needs the same thing. Instead, the model describes a logical progression across different zones:

1. Focusing on Value (Zone 1 - Core Competence):

• Teams in this zone focus on understanding and applying their agile practices to create value for their customers.
• Here the emphasis is on the foundation of agile principles such as iterative development, continuous feedback, and working products.
• The goal is to master basic agile skills while maintaining a clear focus on creating value for the customer.
• Through practiced transparency, one gains better insight into the teams’ work. Furthermore, the possibility to change direction quickly emerges.
• Necessary investment: Team development and adaptation of work processes (e.g., by introducing Scrum).
• The authors estimate it takes between two and six months to reach this zone.

2. Delivering Value (Zone 2 - Expansion):

• Teams in this zone begin to extend their agile practices to the needs of the organization.
• They work on expanding their capabilities to not only create value for the customer but also make the organizational environment agile.
• This can include integration with other teams, collaboration with other departments, and adapting to organizational changes.
• This zone is characterized by higher productivity and fewer technical defects as Extreme Programming and DevOps are practiced. Through CI/CD, deliveries are made both frequently and with high quality.
• Reaching this zone takes an estimated three to 24 months. During this time, lower productivity is to be expected as skills need to be built up.

3. Optimizing Value (Zone 3 - Optimization):

• Teams in this zone optimize their way of working and their agile practices to achieve maximum efficiency and effectiveness.
• The focus is on continuous improvement, automation, and reducing waste.
• The teams understand what the market wants and can react to it independently and quickly. The entire process from designing a product to its delivery is in the team’s hands. As a result, the authors promise even higher-quality products and better project decisions.
• It takes years to reach this zone of fluency. The skills of the previous zone must absolutely be learned. Continuous Product Discovery, Design Thinking, Dual Track Agile, etc., are not foreign concepts here. To reach this zone, the organization must invest social capital in shifting business decisions and expertise.

4. Optimizing for System (Zone 4 - Innovation) - the future of agility:

• Teams in this zone are not only agile internally but can also react flexibly to external influences.
• Any organization aiming for a focus on innovation engages with organizational theory, Open Space Agility, Sociocracy, and Holacracy.
• The authors emphasize that this zone has not yet been researched enough and is speculative.

Application of the Model

The clear structure and the focus on value, team, system, and market make it a versatile tool for those who want to fully exploit the benefits of agile methods without (immediately) focusing on the goal of reaching the final zone. The model serves as a basis for conversations about the step-by-step development of teams and further organizations. Its advantages are obvious. Each zone is well described, particularly with regard to expected:

• Investments/Costs
• Duration
• Results and Benefits.

Based on these characteristics, it enables any team to weigh in which direction / how far it wants to develop. Should a team not see the benefits of the respective zone despite its efforts, it can quickly find out what is missing using the descriptions.

Are there disadvantages? Yes. The model may sometimes seem very general. It is not an instruction manual with detailed information. Knowledge of other models may be required. In addition, good knowledge of the field of agility is essential. As a critique, it can also be mentioned that the model is based on long-term observations by the authors who advise organizations. It is not scientifically proven in any way. Nevertheless, it offers a good evolutionary guide for teams and companies.

Conclusion

The “Agile Fluency Model” by Larsen and Shore offers a practical alternative to traditional maturity models. It serves as a guide for teams to improve their agile practices without necessarily having to reach the highest level. Despite some points of criticism, it provides a clear structure for the step-by-step development of teams and helps to effectively use the benefits of agile methods.

Images and other credits!

• Cover image: Photo by Josh Calabrese on Unsplash