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.

The Scrum Master's leadership style is based on the team's level of maturity

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

Mature teams have a working way of solving problems. Problems are not shoved under the rug, they are openly discussed and actively resolved. In all but the most special cases, the Scrum Master is not required as part of the solution.
Teams with a low level of maturity may choose to ignore known problems or require active intervention from the Scrum Master in the resolution process. In extreme cases, the Scrum Master needs to solve the problem for the team.

Collaboration

Mature teams are mostly focused on the shared team objectives. They arrange their activity and collaboration around delivering value to the customer. 

Immature teams tend to focus on the work of each team member. There are many handovers in the delivery process. People think in personal functions rather than business outcomes.

Getting things Done

Mature teams don't like to stack up undone work. They like to work on as few items as possible and get these done as fast as possible. They won't touch a new backlog item until their last one is Done.
Teams with a low level of maturity might shy back from "tough" work and put it on hold until more information becomes available or until the problem "disappears".

An easy assessment of the team's maturity is a quick glance at the Scrum board throughout the Sprint: Is WIP limited, how fast are items moving from "In Progress" to "Done"?

Process change

Mature teams constantly modify their ways of working. They continuously use controlled experiments to break their process in order to discover new, better ways of developing software. It's impossible to formally define their process, because by the time you'd jot it down, the documentation would be outdated.
Immature teams either meddle with their process without deeply understanding the impact of their action - or they are too scared to experiment without having formally approved the change in a Retrospective. They might even prefer a clearly defined process to follow and would rather master this process than make a disruptive change.

Ceremony behaviour

Mature teams run their own ceremonies and they get the necessary outcomes to continue working effectively. Immature teams need active facilitation and moderation - in some cases, even content guidance to reach the intended outcomes. Extremely immature teams will skip the meeting unless the Scrum Master actively invites them.

In general, ceremony conduction follows a bell curve: Learners spend less time, because they don't see the need, advanced practitioners invest a fair amount of time to maximize the effectiveness of the ceremony - while mature teams obtain the same outcome with significantly less effort, following the 10th Agile Principle of Simplicity.

Ceremony effort curve:

The Ceremony Effort curve needs to be clearly understood: For an outsider, there is little difference between a "Shu" learner and a "Ri" Grandmaster. Observing the team mechanics in detail and understanding the intended outcome very thoroughly is essential in determining whether you're encountering a mature team or not. Oftentimes, immature teams consider themselves mature.


Daily Scrum
Immature teams "report status" and "track progress". They are more focused on their portion than on the team objectives.
Mature teams use the Daily to sync each other and come up with the most sensible team plan for the next 24 hours.
Really mature teams don't need much of a Daily, because they are continuously planning and continuously syncing.

Refinement
Immature teams don't refine or delegate refinement responsible to the Product Owner: The Sprint Planning is often an unpleasant surprise for all those involved.
Mature teams refine in mutual interaction between stakeholders/customers, PO and team. They meet as often as necessary to guarantee enough "Ready" backlog for the next Sprint Planning.
Really mature teams don't need to refine, because they have mastered the art of delaying decision making to the latest possible moment. They are comfortable with lacking clarity until they actually start developing. The need to acquire information does not affect their development speed.

Planning

Immature teams are often befuddled at the intention of Planning. The typical beginner's planning looks like this: PO introduces Product Backlog items and asks "Do you have any questions?" (no). Then, the team decides what to work on, occasionally doing estimation and task breakdown. (Usually, the plan doesn't work out because significant items were missed.)

Mature teams use the Planning 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. They might argue over the solution, as there is not "one best way" to do things.

Really mature teams use the Planning ceremony to get a quick glance, as they are comfortable with delaying detailed decision making until they actually work on the item. They are clear on the intention and approach because of deep, shared understanding.

Review
Immature teams fail to hold Reviews or do so ineffectively. It's more of a Demo and approval session. In extreme cases, it becomes a blame session where stakeholders accuse developers of misunderstanding or developers accuse stakeholders of miscommunicating.
Mature teams use the Review as a tremendous mutual learning opportunity, gaining deeper insights into the customers' minds and enabling the Product Owner to add more value to the backlog.
Really mature teams don't invest much into the Review, because they continuously gather information about customer needs and satisfaction in real time.

Retrospective
Immature teams use the Retrospective as a small break from "real work". The outcome of a beginner's Retrospective is often an obvious change with marginal impact on the delivery capability. The question, "Why are we even doing this?" is quite common.
Mature teams dig deeply into their process to unearth hidden pitfalls and treasures. They take the chance to discover significant improvement potential in their ways of working.
Really mature teams use Retrospectives as a reflection space to find different ways of achieving a better outcome with less effort.

Interaction

This topic follows the same kind of bell-curve progression as the ceremonies.
Immature teams shy away from communicating with each other or the Product Owner. Developers somehow try to progress individually. Especially the Product Owner has very little touchpoints with the team - except for Planning and Review.
Mature teams communicate constantly with each other and the Product Owner. No question is too trivial or too difficult to ask - what counts is building up a common understanding. The team probably wouldn't even miss the PO during Review, as they already know the PO's shot at their results.
Really mature teams have a high degree of common understanding. Discussions start to center around  synchronization and innovation. The overall need for discussion might decrease when work is easy to modularize.

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.