Agile Maturity Model – create one in 4 easy steps

Maturity models are frequently used as tools to help assess a process or an organization.

In Agile implementations, it is not uncommon to use check-lists, health checks, maturity models with a similar goal in mind.

Why are Maturity Models useful?

Agile implementations, or similar big fundamental changes, to the way we work, take time. While we start with some desired state in mind, we usually evolve to that stage over months and sometimes years.

Having a maturity model or a similar tool helps us look at the big picture, to see areas where we are making good progress and areas which need more TLC.

Maturity models are also a great way to keep the end (-ish, because the journey doesn’t really ever end) in full view for all. It shows what we are gunning for.

Building a Maturity Model

While a maturity model may actually assess process maturity, it is important to have the outcomes as the primary focus.

This way, even if our process or practices change, we can still use the basic framework of our maturity model which is based on outcomes.

For instance, if one of the reasons for doing an Agile Implementation is to improve the team’s ability to respond to change, then we would like the maturity model to show how the team is maturing in “Responsiveness to Change”. Or if delivering high quality software is a desired long term outcome, then we would like to visualize through the maturity model, how far along we are in the journey in “Quality”.

So, step 1, is to pin down the desired long term outcomes we are trying to effect through the Agile implementation.

So the outline of the maturity model after this step may look like this, for instance:

Maturity Model Step 1 - Outcomes

 

Once we have the outcomes pinned down, we need to actually build the questions using which we can assess process maturity – towards our outcomes.

For instance, if the team believes that Pair Programming improves the Quality of our software, then the maturity model may have a question asking specifically “Does the team use pair programming regularly for writing code?”

Or if the team works in short sprints to make us better suited to respond to changes, a question like “Does the team work in sprints that are 2 weeks or shorter?” may find place in the maturity model.

So step 2 is to figure out what are the questions that help us assess the process maturity which helps us make progress towards the outcomes we have in mind.

So the Maturity model at this stage may look like this:

Maturity Model Step 2 - Questions

 

Now comes the “maturity” part of the maturity model.

A maturity model recognizes that change takes time and process maturity evolves.

How a team behaves when starting with an Agile implementation and how an experienced team behaves, are vastly different. So the questions in the maturity model need to reflect this growth in maturity.

So step 3 is to take the questions and order them by “maturity”.

For example, a new scrum team may simply start having daily scrum meetings as a practice without fully extracting the value from it. So a question about “Does the team meet daily for a 15-minute daily scrum meeting?” may be appropriate in early days. But as the team matures and learns the value of the ceremony, a more relevant question might be to ask “Does the team challenge and improve the process of the daily scrum meeting?”

For each of the outcomes identified in step 1, we would have a list of questions ordered by maturity.

It also allows us to categorize the questions according to maturity – for instance “Beginners”, “Experienced”, and “Experts” or similar.

How do we score the questions? We keep it simple.

We design “Yes or No” questions with a score of 1 for Yes and score of 0 for No.

This now helps us identify where on the chart we would be if we answered yes for all the “Beginners” questions, and so on.

The maturity model may look like this at this stage:

Maturity Model Step 3 - Order the Questions

Finally …Color codes and their significance

Visually, it is important to color code the stages of maturity. However we do not want to fall into the RAG (Red-Amber-Green) trap.

Being a beginner is not a red status – it simply shows where we are in the journey.

So we use any colors, other than the RAG scheme (or schemes with similar connotations) and keep any misinterpretation of the model at bay.

Here’s the maturity model in its full color and splendor:

Maturity Model Step 4 - Visualize

 

Maturity Model Do’s and Don’ts

Often, a well-designed maturity model can be defeated by poor usage.

Here are some tips to using one:

  1. Use it frequently but don’t overdo it – so once in 2-3 months, just before a retrospective is probably a good place to assess the maturity. The maturity assessment can be a great input for the retrospective.
  2. Answer the questions together as a team with a facilitator helping you discern the questions when required. This is also a good opportunity for the facilitator to improve the teams’ understanding of the process and to show the end goals to the teams (give them something to aspire for).
  3. Use the maturity assessment outcomes to find the areas needing extra attention and look for improvements there.
  4. Do not use it as a governance tool for management – management may however look at accumulated trends across the organization to draw improvement items for them to act upon.
  5. Do not use it to evaluate or compare teams – every team is on their own journey with their own contexts, strengths and constraints.
  6. Don’t sweat the details – exact scoring, minute variations etc do not matter in the larger scheme so just ignore them.

 

Here’s what a maturity model with assessment done may look like:

Maturity Model Sample Assessment

 

So in summary, here’s how to build an Agile Maturity model:

  1. Step 1 – Identify the long term desired outcomes
  2. Step 2 – Identify the practices that help us go towards our desired outcomes – translate them to simple “Yes/No” questions
  3. Step 3 – Order the questions by maturity levels and group them
  4. Step 4 – Have a clear visual representation of your maturity model and assessment
Advertisements

Building an Army of Volunteers

Enlist Today

Kotter’s new Accelerate model

In John P. Kotter’s new change model – Accelerate! – he talks about how promoting the change through established hierarchies alone can actually be detrimental for modern organizations.

He talks about the existence of the informal strategy network – a flexible, adaptable structure that is populated with employees from all across the organization – up and down its ranks.

And he proposes a dual operating system for driving change – a management-driven hierarchy complemented by the strategy network!

So the approach is that of “and” and not “or”. Both, the hierarchy and the network, have a role to play.

What is a volunteer army?

“Many people driving important change, not just the usual few appointees”: Kotter’s vision is to attract a “volunteer army” of employees from the informal strategy network who buy in to the message of change and are committed to it, an army of volunteers who participate actively in problem solving, innovation and collaboration.

Why do people volunteer?

Before we start looking for ways to build this volunteer army, we need to understand why people volunteer.

Think about the last time you volunteered for something – at work or outside of work. Think about why you volunteered.

Did you do it since it provided you an opportunity to learn?  Did it give you a sense of satisfaction? Did you do it as a favor to someone?

Broadly speaking, people are motivated to volunteer by one of three reasons –

  1. Self-serving drive – what’s in it for me?
  2. Relational drive – because “xyz” asked me to …
  3. Belief drive – I am passionate about the cause

What Kotter says about getting volunteers?

Kotter’s tips on motivating volunteers stress on creating a feeling of the volunteers “getting to” do something rather than “having to”. Also appealing to heart and head is more likely to get us results than appealing to logic alone.

How to recruit volunteers

How to recruit a Self-Serving Volunteer?

WIIFM

Target this group by helping them answer questions like:

  1. Will I be seen as an expert by doing this?
  2. Does it make my resume more attractive?
  3. Does it help me grow?

So incentives like certifications, awards, skill-building, opportunities to share new knowledge publicly and others may work here.

How to recruit a Relational Drive Volunteer?

people-network

This is largely driven by the recruiter’s personal networking skills and how much s/he invests in these relationships – it takes time and effort to build such relations.

How to recruit the Believers?

Purpose

  1. Talk about the Why instead of the What or How
  2. Don’t expect full alignment on How
  3. Be completely transparent with this lot – about benefits and shortcomings of the change

Consult them in designing the solutions

Finally, for all volunteers –

Make volunteering easy!

Not just ceremonial

If you woke me up in the middle of the night and asked me to choose between Kanban and Scrum, I would choose Kanban in the blink of an eye.

(In addition to bashing your head in, because what are you doing in my house in the middle of the night, waking me up to ask me questions about Scrum and Kanban :D)

That said, I also think that the Scrum framework is very powerful and very well-designed.

It is quite fashionable today to say how the ceremonies of Scrum are not important – the mindset is.

Well duh! Sure!

But are we downplaying the importance of the ceremonies?

Is it fair to be dismissive of the ceremonies is all contexts and environments?

Aren’t ceremonies a great vehicle to bring about the aforementioned and much-coveted mindset change?

Isn’t each scrum ceremony designed in a way to expose underlying constraints and impediments?

Teams don’t participate in Iteration Planning – could expose empowerment or ownership issues!

Daily scrum takes considerably longer than 15-20 mins – could point to intra-team communication and collaboration challenges!

Retros are a drag and are frequently skipped – could be because teams struggle to implement any of the improvement items.

And so on!

Am I advocating the mindless pursuit of ceremonies – of course not!

But ceremonies are a great starting point for teams –

as teams mature and grow, they will experiment and spread their wings and fly and I will give them a push off the cliff to help them along.

But to start with I wouldn’t dismiss the ceremonies as merely ceremonial.

Ceremonies create muscle memory – they help create cultural change….dare I say mindset change!!

Being an Agile Coach – What does it take?

At work, my role is that of an “Agile Coach”.

Now I have been vaguely aware of what it means to be a coach but recently I have invested some time in reading more about the skills and values a coach should espouse (better late than never, right?).

Sharing what I was able to gather so far – some of these I practice with some degree of success, while for others, I have a long way to go.

  • Empathy – The first step for a coach towards connecting with a team is to understand their situation, their strengths, and their challenges. Listening skills are the key to develop such empathy – as I read somewhere, listening for understanding and not for replying.
  • Respect – As an Agile Coach, one may have more experience, exposure, knowledge in some of the Agile practices, etc but the team knows more about the work they do, their current processes, the business, the products. And a coach who acknowledges that will be able to also appreciate that the solutions will come from the team, with him/her simply helping them find their way.
  • Integrity – As a coach, the only agenda should be to help the team build its capabilities and help them discover how to improve the way they work. The coach doesn’t have an agenda of his/her own and doesn’t guide the team in directions that suit him/her rather than the team. The coach is not “selling” the currently popular ideas or fads to the team but helping them find what works best for them.
  • Courage – As a coach, there will always be situations where one needs to help a team face hard truths. It won’t win the coach any popularity contests but if done right, with no finger pointing, it can only benefit the team.
  • Knowledge – Knowledge about the subject, knowledge of coaching skills, tools and techniques to help the teams – all of these are crucial to being an effective coach. For this, the coach should be open to learning – from peers, from books, from conferences, et al. Having an opinion is important, but being opinionated just stops one from learning.
  • Cares about people – I think without genuinely caring about people, it’s a pretty big ask to “help”, “enable” and “empower” people. A coach may care more about the people than about the business. I read something very nicely put recently “If you take care of your people, your people will take care of your customers and your business will take care of itself (JW Marriott)”.
  • Creating independence – Asking empowering, leading questions is considered a pretty important coaching skill – to help the team discover solutions. A note of caution though – I tried it (a little incessantly, I admit) on a friend and he wanted to punch me in about 5 minutes. So it’s trickier than it sounds :).

So these are the ones I am working on developing and improving upon for now.

Not easy to do but hopefully it will take me closer to being a real coach rather than just being a coach shaped object (idea borrowed from “bike shaped object”).

Intuitively Agile

The Agile Manifesto starts with talking about how Individuals and Interactions are more valuable than Processes and Tools.

As an Agile coach, I find that while it is still relatively easy to get people to start practicing “practices”, the heart of Agile – the “people” – is the toughest part. But I have come across some managers who are “intuitively Agile” (you know who you are).

And they are not necessarily people who are “doing” Agile.

These are people who invest in building motivated individuals around them – they start out with the similar people as others but grow them into enthusiastic, passionate, high-performing team players. And these then in turn start exhibiting similar traits in developing more people creating a domino effect.

These are people who create a safe environment for taking risks and failing fast. This allows their people to experiment and innovate knowing fully well that when they fail, they have their managers backing and support to get them back up on their feet.

These are people who empower their team members while expecting them to take responsibility and ownership over their work. They allow them the freedom to take decisions by cutting the bureaucracy and decentralizing decision-making.

These are people who demonstrate every day that titles don’t matter – if developers need a helping hand and these managers can don that hat, they do. If testers need help, they do what they can to help. Roles and titles are “guidelines” and not rules.

More power to their tribe!!