Six simple ways to understand Scrum team maturity

When you're a Scrum Master, working an a new environment - with a new team, it's imperative to have a good understanding of the team's agile maturity. Why? Teams with low maturity need more guidance - teams with high maturity need more opportunities to reflect. To not be the Elephant in the Glasshouse and spoil your relationship with the team early on, you need to understand how mature your team is before you act.

An immature team may require you to not only clearly facilitate the Retrospective - you may even need to uncover a meaningful topic for a Retro beforehand to direct the team, so that they don't just waste time. On the other hand, a mature team may not even need anything from you in a Retrospective as they have deeper understanding of the How, What and Why than you might have.

With this fairly self-explanatory model, here are a few pointers to help you determine how mature your new team is. Note that this is not a binary scale - it's more a gradient that can be anywhere and vary for different topics.

Problem solving

Do team members discuss problems openly? Do they actively resolve them without the Scrum Master?

Collaboration

Do team members arrange their activity and collaboration around delivering value to the customer?

Getting things Done

Does undone work stack up? Do developers work on as few items as possible and get these done as fast as possible? Are new backlog item started before others are moved to Done?

Process change

Do developers continuously use controlled experiments to break their process in order to discover new, better ways of developing software?

Ceremony behaviour

Is there a need for a Scrum Master so that the team run their own ceremonies? Do developers get the necessary outcomes to continue working effectively?

Daily Scrum

Do team members sync each other and come up with the most sensible team plan for the next 24 hours?

Refinement

Is there mutual interaction between stakeholders/customers, PO and team? Do they meet as often as necessary to guarantee enough "Ready" backlog for the next Sprint Planning?

Planning

Is Planning used as an opportunity to explore intentions behind each item and come up with hard questions to challenge their own understanding of the request and how it should be implemented? Are there arguments over the solution, as there is not "one best way" to do things?

Review

Is the Review perceived as a tremendous mutual learning opportunity, gaining deeper insights into the customers' minds? Does the Product Owner get to add more value to the backlog?

Retrospective

How deeply will developers dig into their process to unearth hidden pitfalls and treasures? Do they discover significant improvement potential in their ways of working?

Interaction

How often do you see developers communicating with each other and the Product Owner? Are there question considered too trivial or too difficult to ask?

Summary

Look at these six patterns: Problem solving, Collaboration, Getting things Done, Process change, Ceremony Behaviour and Interaction. This will give you a fast and thorough understanding of how mature your team really is. You can adjust your own behaviour as a Scrum Master to accommodate the needs of the team.

About the author

Michael Küsters is an agile consultant/coach/trainer helping clients from small startups to international corporations throughout their agile journey.

This article is an abridged form taken from my personal blog, "Fail fast, move on". By clicking on the provided link, you will find a more comprehensive version of the article that has additional pointers for identifying immature teams and drawing the line between "Shu" level beginners who don't understand Scrum yet - and "Ri" level masters who have transcended the form.