|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 solvingMature 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.
Getting things DoneMature 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".
Process changeMature 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 behaviourMature 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.
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.
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.
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.
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.
InteractionThis 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.