As an Agile coach, I lately found myself in the position of having to “measure or diagnose” the Agile maturity of an organization. At the same time, I got the opportunity to play the Ben Linders’ (*1) Agile self-assessment card game with one of the Scrum teams I coached and lately read Linders’ book which comes handy if you wish to extract the maximum potential of the author’s Agile self-assessment card game.
This is what I learned:
As they say:
“If you can’t measure your work, how do you know you’re heading into the right direction?”
Certainly, if my client had started seeing the benefits of the Agile journey among teams and witnessed visible results, such a request for measuring Agile maturity would probably not have emerged, right?
So, the “need” for diagnosis probably comes from an assumption or shall I say the “perception” that the teams are stuck somewhere in between “implementation” and getting real value for it.
Now, would I have had the opportunity to take a step back, I probably would have invited my client to do the same and answer the following questions: “why” would you want to diagnose the Agile “maturity” of your teams and what exactly do you want to measure? What are you looking for?
I would probably have gone into explaining that Agile “maturity” or shall we say “capacity” is simply not “measurable”. Agility is not something absolute or set in stone. It’s more of a journey and it is relative. As a reminder, Agile is value driven and adaptive and the vision creates features estimates.
So, let’s assume the purpose of measurement is to be able to compare one’s own organization’s performance with others… I could have proposed my client to look up the Mike Cohn Tool.
The Mike Cohn tool collects and stores your results in their cloud so you can compare your data collections with industry/global indices… you can see how other players on the market are going on engineering practices for instance or how Agile culture is doing these days. It surely will contribute to uncover where your team stands comparing to market/global index and gives you direction, not a diagnosis per say.
But, I would have probably end up telling my client that one thing this tool or any other great exaction and analysis tool like that will never bring him/her is precisely TRUST: If you don’t believe that people can assess their current state objectively enough, why did you hire them in the first place?
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Agile Manifesto.
The search for a way to measure the Agile maturity/capacity of an organization reminds me of traditional big transformation programs with a project’s predictivity approach and a top-down mindset where managers want to plan how to increase maturity by xx% so that transformation will be considered successful. What is considered “success” for an Agile implementation anyway?
“In complex environments, what will happen is unknown” (…) “Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation”. Scrum Guide.
Now that organizations are starting to realize that the world has gone VUCA, volatile, uncertain, complex and ambiguous, the need for T.R.U.S.T(*2), Transparency, Recognition, User-oriented, Self-awareness, TShapingseems to be slowly replacing the need for predicting “maturity” or monitoring key performance indicators and this is where self-assessment tools come handy and appropriate.
Impact perception and observable change rather than tools to measure!
“Working software is the primary measure of progress”. Agile Manifesto
Monitoring performance should rely on impact perception (observable change) rather than on an external audit. At least, that’s what I learned trying to build a “diagnostic” radar based on some famous existing tools such as the The Scrum Checklist or the Squad Health Check model from Spotify/Henrik Kniberg.
Self-assessment tools stand as typically appropriate in C.A.S (Complex adaptive systems) as they are empowering and helpful techniques for teams.
Because an assessment game is first of all a game (not a questionnaire or a face to face interview with a person in charge or giving a mark) it helps generate spontaneous conversations, facilitates discussions on future improvements and allows team members to step back on their work and self-evaluate where they really are and where they should put their focus on in order to improve.
Nothing is indeed as powerful as gamification according to Ben Linders who lists a large number of tools on his website to help you put together a Health Check Up or self assessment. The Agile consultant describes gamification as a way to “engage and involve people”.
In his new book “The Agile Self-Assessment Game — An agile coaching tool for improving the Agility of your teams and organization”, Ben Linders explores ways to get the most of his “Self-assessment” card game he created some years ago. This is an inspiring journey during which the author explores different ways to use the game and provides techniques, ideas and “experience stories” from other people in order to better apply self-assessments to an organization.
For the author, Agile methods and frameworks like Scrum, Kanban, SAFe or LeSS, don’t tell you how to increase your agility. They provide practices, roles and activities and a structure which fits them together. But they are no “recipes that can help you truly become agile.”
With this card game, “everyone wins if they share and collaborate and there are no losers” Linders notes!
But this is not just another card game: in his latest book, Linders parses some ingenious ways to play the game and makes a compilation of situations where you can benefit from the full potential of the card game. Among Linders’ playing suggestions, we start to learn how to use the cards in a more classi way during a Scrum Retrospective meeting, or doing an agile health check based on a radar chart.
But some suggestions come out of ordinary, I particularly enjoyed discovering the “First things first” way of playing the game where each member got to decide for him or herself what are the top improvements priorities.
“The best or worst Agile Practice Contest” or “Learning by sharing challenges” both stand among one of the most original playing formats described, the latter being particularly useful when you want to spread knowledge and share practices among several teams. Competing for creative ways of playing Linders’ cards game, let’s also mention the “Angel’s advocate” to stimulate creativity and positive thinking, “Two truths and a lie” based on the icebreaker of the same name or last but not least “1–2–4 all from Liberating Structures” where people can discuss in pairs, then foursomes and finally as a whole group.
At the end of the book, Linders lists a bunch of Agile Self-Assessments tools which you can also find on his website.
The game comes with expansion packs on specific areas you might want to focus on when self-assessing such as Scrum, DevOps, Business Agility and Kanban. It also comes in several languages, the French language.
So, why would you measure Agility and determine an Agility percentage?
Make a customer survey instead with questions covering responsiveness, features quality, features value, support provided, delivery timeliness etc.
But in any case, don’t forget to inspire your teams with Agile games such as self-assessment games.
“Don’t manage the people, manage Environments!” Jurgen Appelo
Metrics do no drive team performances. Metrics are not inherently good or bad, it is the use of the metric that drives team dysfunction.
“Agility can be learned by practicing and helping others improve rather than by elaborating an ideal solution ready to be deployed by some Change agents.
“Individuals and their interactions are keys and more important than strategic plans and top-down communication
“You should provide context and support to sustain motivation of your self-organized teams in order to satisfy your client rather than counting the number of “Agile-trained” teams you have in order to follow rules and tools.”
Christophe Keromen — Extract from SOAT Conference Jan. 2019. Maison du Management. Freely translated/adapted from French.
(*1) Ben Linders is an Agile Consultant/Speaker and the author of several blog articles, books and Agile Coaching Tools. More information can be found on his website.
(*2) T.R.U.S.T don’t fool yourself believing this acronym is registered somewhere, it is something I came up with for this article, do you like it?