There is no doubt that a scrum master’s role is seen as a leader. A leader should also be prepared to adjust their leadership style to provide what the group may be missing. This would compliment the team. Other times the team might be best served by capitalizing on their strengths and instead augment them. Yes, there may also be times when the team is so empowered that for a short while they may be almost invisible; sharing the leadership with others. A scrum master might consider being lenient with some processes in the cases where the team is showing respect for the agile principals.
A Scrum master will grow a team. Keep the team and the organization continuously improving. The ability to identify where a team is in its maturity will help. To be clear, a team’s maturity has little to do with the time spent together and is more about the characteristics of the team. How do they interact? How well do they tackle some fairly thought-intensive work?
Bruce Tuckman described 5 phases to team formation. All these phases required common tasks or goals for the team to align with. While the product owner’s abilities lay in the analysis of unfolding information; the scrum master’s job is to facilitate the team’s transition through towards becoming more mature, shaping the interaction.
Here the scrum master is a trainer. This group of individuals may be seeking acceptance and may feel relatively uninformed. Being more directive while members of the team seek acceptance and start orienting themselves.
Still as a trainer, the team may be expressing some dissatisfaction as they test limits and boundaries. Many different ideas are competing as they form acceptable leadership behaviors. How the team deals with conflict will stop them or help them move onward. Does the team focus on minutia or avoid real issues? How is time spent?
Now as a coach, the scrum master is helping the team integrate with one another. The team has a goal and a mutually derived plan. Some of the team members may have to acknowledge and help champion an idea that was someone else’s or perhaps even contrary to their own. All done towards achieving the group goal.
Now as a Mentor, the scrum master is seeing the team produce. The team has a rhythm and perhaps even a swagger as they operate smoothly and are able to problem solve effectively without much conflict. There is a high trust among the team members.
Things with beginnings also have an end. Having closure, ending, celebration, recognition and reflection are all part of this cycle. If the team delivered, celebrate and recognize the team for the win! Not every ending is ideal however. Say that a team has worked 6 months to deliver a product, has a sustainable pace AND met their deadline but the product is never put to market by the company. There is no closure to the goals that have been the vision of the team for so long. Motivation will certainly be affected. It might take a while to get going again. So too the loss of a team member… even one lost to promotion. Keep visibility and an openness as teams deliver or maybe even wind down projects, deprecate portfolios, and assign applications to obsolescence.
Being an eternal peacemaker within the team might even inhibit a team advancing from norming to performing. The largest caveat here is that the journey is not always a linear one. The team can revert or be thrown into ANY of the stages for a time. Maybe a new member has been added, or a particular stressor has the team acting differently.
Another way to look at a team’s maturity is to gauge the capability and characteristics. Every team has it’s own unique identity, and watching an agile team work is organizational behavior.
12 Criteria for measuring the maturity of a team
- Feedback Mechanisms (poor -> excellent) Does the team adapt? How long does it take to adjust? Does it revert to a defensive posture when questioned or is it more reflective and thoughtfull? Does the team possess and agile mindset where they exhibit iterative, time-boxed and incremental improvement?
- Decision Making Methods (dysfunctional -> functional) This is bad when a head is locked up in a little view or single perspective.
- Group Loyalty / Cohesion (low -> high)
- Processes and Tools (inflexible ->very flexible)
- Use of Member resources (poor -> excellent) Does the team exhibit swarming behavior? Is everyone efficient and effective? Are we challenged and utilized?
- Communications (unclear -> clear) Does the team talk? Can I hear them? Does the team participate and help inform the organization? Are they visible with information radiators that are up to date and aligned?
- Goals (unclear -> clear) The Product Owner will answer what is next, while the team will be able to explain their vision, how we will get there, and how we will know if we are there yet.
- Problem-Solving Ability (simple -> complex) Does the team stall out when presented with a challenge or do they forge ahead? Are the solutions brittle or robust?
- Participation in Leadership (low -> high) Is the team engaging, challenging and growing the organization around them. Great teams have and influence others and benefit those around them. What about outside the organization and in the community?
- Acceptance of minority views (low -> high) are the quiet ones considered or even invited to speak? Is is just one person’s opinion again and again? What about all the different perspectives that might use or even abuse this product?
- Standards (low -> high) Is the quality of work high? Are there defects or rework that make others avoid this team? Is this team’s work readily accepted and meet a definition of done that sets a new level of expectation.
Just remember that where your team(s) might be,– is just the start of where they might go.