Agile Audit: How Is Your Agile Transition Progressing?

TL;DR: Agile Audit

Supposedly, becoming agile is a journey, not a destination. Which is a convenient narrative if the viability of your consultancy depends on selling men and materiel. The fuzzier the objective of an agile transition the less likely there will be an agile audit addressing the return on investment question the customer might have.

Moreover, a fuzzy objective such as ‘we want to become an agile organization’ is probably the reason for applying the same methodologies indiscriminately to every organization — a one size fits all approach for agile transitions.

However, what if not every organization embarking on a transition to agile practices is meant to become a teal organization or a holacracy? What if being late to the agile transition party is instead a deliberate choice than a manifestation of hubris, ignorance or leadership failure?

Read more on why feedback loops in the form of an agile audit are beneficial for organizations and teams alike.

Becoming Agile, Late Majorities, and Laggards

InfoQ applies the ‘Crossing the Chasm’ metaphor to engineering practices, thus covering a part of the agile movement to create learning organizations. Its recent ‘Engineering Culture and Methods InfoQ Trends Report — January 2018’ found that new converts to Scrum, for example, will recruit themselves most likely from the late majority and laggards. (The early majority of organizations is already adopting Lean, Kanban, and Scrum derivatives.)

Copyright notice: InfoQ, 2018. All right reserved.

Regarding the late majority and laggards, my two working hypotheses are:

1. Not every — late majority or laggard — organization embarking on a transition to agile practices now would benefit from automatically following the beaten path of preceding organizations. Why strive to become a holacracy if there is no value for customers to be gained? (Think about markets that are highly regulated.)
2. Many of the innovators, early adopters, and early majority organizations would benefit from external feedback loops in the form of an agile audit, too. The majority of these organizations are anyway operating somewhere on the product delivery side of the agile equation. They have never progressed to embracing business agility as an organizational concept. Moreover, they probably overspent on their agile transitions as they missed to define a goal at the beginning of their journey. Note, it is not in the interest of a consultancy supporting clients with agile transitions to make itself redundant in the process.

Agile Transition — A Manual from the Trenches

Download “Agile Transition — A Manual from the Trenches” for free

Download your copy of the latest, 191 pages strong version of “Agile Transition — A Hands-on Manual from the Trenches” for free here.

The DIY Agile Audit — Self-Assessment Tools

Ben Linders lists more than 50 self-assessment tools that provide some status check of a team or even an organization.

A lot of these self-assessment tools are suited to provide an initial data set to start a discussion with a team or the organization. (See, for example, my questionnaire Cargo Cult Agile: The ‘State of Agile’ Checklist for Your Organization.) If applied in a regular cadence, a change of the resulting values over time may support a better understanding of team issues as well as organizational issues and other contributing factors.

One of the best-known self-assessment tools is probably Hendrik Knibergs “Unofficial Scrum Checklist:”

In the example above, we were using a kind of estimation poker to answer each question with one of the three values green, orange, and red. The colors are coded as follows:

• Green: It worked for the team.
• Orange: It worked for the team, but there was room for improvement.
• Red: It either didn’t apply, for example, the team wasn’t using burn-down charts, or the practice was still failing.

If the resulting Scrum practices map is getting greener over time, the team is on the right track. Otherwise, you have to dig deeper to understand the reasons why there is no continuous improvement and adapt accordingly.

What most of these self-assessment tools are lacking, though, is alignment with an overall concept how agile transitions occur. Hendrik Kniberg’s Scrum checklist has proven to be a useful tool providing insight into the progress of the adoption of Scrum practices at a team level. However, adopting Scrum, for example, is only a minor part of becoming an agile organization.

This alignment applies particularly to larger organizations where the excitement to experiment with agile ways of working is often sidelined both by the “what-is-in-for-me-syndrome” of the higher levels within the hierarchy as well as the risk mitigation necessity. This is where the Agile™ Fluency Model appears on the scene. James Shore and Diana Larsen initially described the model on Martin Fowler’s blog back in 2012: Your Path through Agile Fluency — A Brief Guide to Success with Agile.

Please click the “clapping hands” 👏, if you found this post useful–it would mean a lot to me!

If you prefer a notification by email, please sign-up for my weekly newsletter and join 14,997 peers.

The Agile™ Fluency Model by James Shore and Diana Larsen

In October of 2017, I attended the Agile Fluency™ Gathering 2017 which happened to be in Germany. I wasn’t sure what to make of the model in advance, but meeting dedicated agile peers in general and Diana Larsen and James Shore, in particular, seemed well-spent time to me.

The gathering started with two days of introduction to the Agile Fluency™ model stressing particularly that it is not a maturity model.

Instead, the steps that may look from the outside like maturity levels turned out to be fluency zones. Each zone constitutes a valid level of organizational agility. Also, a combination of elements of more than one zone can define an organization’s agile fluency. That was my ‘aha’-moment.

About 60 percent of ‘agile’ organizations seem to fall into zone one (Focus on Value), about 30 percent belong to zone two (Deliver Value), while five to ten percent can be assigned to zone three (Optimize Value). There is no valid data available on possible candidates for the zone four — Optimize for Systems — as there are only a few companies known to be in that zone. (For example, Semco, or Menlo Innovations.)

Agile Fluency™ Model Zone 1: Focus on Value

Zone 1 of the Agile Fluency™ model is centered around a shift in the team’s culture. The team is now focusing on working on the most valuable things at all time although the road to value-based prioritization will likely be a bumpy one. Nevertheless, from a business perspective progress is already visible. What we observe in this zone, for example, is the application of basic Scrum principles or a switch to Kanban.

These fundamentals will usually take two to six months to master, and approximately 60 percent of all agile teams across organizations fall into zone 1 of the Agile Fluency™ model. (Note that falling in zone 1 does exclude borrowing already some techniques from zone 2.)

Agile Fluency™ Model Zone 2: Deliver Value

Zone 2 of the Agile Fluency™ model addresses team skills, mainly being able to release at will, shipping product on a market cadence, capturing value frequently, and revealing obstructions early. All of this requires investments both in software craftsmanship — from extreme programming to clean code to DevOps — as well creating cross-functional teams.

These steps will typically take from five to eighteen months to master, and approximately 30 percent of agile teams fall into zone 2 of the Agile Fluency™ model.

Agile Fluency™ Model Zone 3: Optimize Value

Zone 3 of the Agile Fluency™ model reflects the shift to improve the organizational value of a team by incorporating business expertise. In zone 3 we talk about applying techniques like Lean Startup or Design Thinking to make innovative product decisions. The team will reduce handoffs, improve the flow of work, and address organizational obstacles that impede the team’s future success.

Depending on the nature of the organization, these fundamentals will take from twelve months to three years to master, and no more than five to ten percent of agile teams fall into zone 3 of the Agile Fluency™ model.

Agile Fluency™ Model Zone 4: Optimize for Systems

Zone 4 of the Agile Fluency™ model is all about optimizing systems by changing their organizational culture. Probably, this means moving toward sociocracy, to holacracy, or teal organizations. Teams understand business priorities and seek to collaborate with other teams to improve the overall value stream, thus propelling innovation in a self-organized manner.

Besides a few (small) startups, there are only very few large companies known to be in zone 4 of the Agile Fluency™ model.

The Agile Fluency™ Team Diagnostic — An Agile Audit Tool

Based on the Agile Fluency™ model, James Shore and Diana Larsen developed a team diagnostic tool.

The Agile Fluency™ Team Diagnostic tool supports an agile team with the identification of the state of its agile journey as well as beneficial next steps. If applied in a regular cadence, patterns will emerge that provide a better understanding whether the team is on the right track improving its capability of delivering valuable products to the customers.

The tool is centered around a questionnaire comprising of seven questions each for the first three zones (from Focus on Value to Deliver Value to Optimize Value) that are answered by each team member. The answers are simple ranging from ‘1/Never’ to ‘5/Always.’ The facilitator then aggregates the results:

Based on the distribution of individual answers, the Agile Fluency™ Team Diagnostic tool provides a visualization of a team’s current status:

A team is “fluent” in a zone when:

1. Everyone in the team rates the zone’s core metric as ‘5/Always,’
2. At least 75% of the team members’ responses (across all seven questions) are ‘5/Always,’
3. The composite (team) rating for six of the seven items ‘5/Always.’

Based on this status according to the Agile Fluency™ model the team engages in a discussion to identify issues worth tackling to improve the team’s fluency. (This is not different from an overall team retrospective.) The Agile Fluency™ Team Diagnostic exercise is then repeated in a regular cadence, probably every 8 to 12 weeks thus creating a pattern.

Once you run this practice with all teams regularly and you aggregate the team results you will create a data set over time that reflects the progress of your organization’s agile transition — the Agile Fluency™ Team Diagnostic can thus become your agile audit.

Note: If you like to learn more about this agile audit tool please me know; I am a licensed Agile Fluency™ Team Diagnostic facilitator.

Conclusion — Agile Audit

Feedback loops have proven invaluable for any undertaking where value needs to be delivered, and risk requires to be mitigated. This fundamental agile principle applies not only to creating products and services. Of course, it does also refer to the process of becoming an agile organization itself.

Hence, feedback loops in the form of a regular agile audit ought to be a part of the toolbox of any agile transition. Not for the sake of collecting data but providing insight and thus guidance promptly for teams as well as the organization.

What is your opinion on running an agile audit? Please share with us in the comments.

✋ Do Not Miss Out: Join the 2,650-plus Strong ‘Hands-on Agile’ Slack Team

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it is free.

Do you want to read more like this?

Well, then:

• 📰 Join 14,997 peers and sign-up for my weekly newsletter
• 🐦 Follow me on Twitter and subscribe to my blog Age of Product
• 💬 Alternatively, join 2,650-plus peers of the Slack team “Hands-on Agile” for free.

Agile Audit: How Is Your Agile Transition Progressing? was first published on Age-of-Product.