Does a team need a Scrum Master?
I've recently observed that sometimes when a team achieves success using agility, management and the team think they no longer require any further coaching, often resulting in the scrum master role disappearing.
So is a Scrum Master needed?
My response to this question is (as usual) it depends. Below are a few questions to ask.
What does a Scrum Master do?
"The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values."
Is my team ready?
Becoming agile is like learning a new language, it takes coaching, lots of practice and time. During the first few sprints, a team new to agile needs frequent coaching from the Scrum master, diligent monitoring of behaviors, and attendance to every blocker. However, once the team matures and become fluent in the 'language of agile' there is less coaching & reminders of Scrum theory and practices required by the Scrum Master.
For example, the Daily Scrum/stand-up is an activity which requires careful attention in the beginning. It is easy for team members to turn the event into an hour long problem-solving meeting, or into a management status report. After a few sprints of stand-ups, the team begins to understand it's usefulness and is soon are running it themselves. (see What is a Daily Scrum)
This leads on to the next important attribute; is the team self-policing? A mature team will gradually begin sharing Scrum Master responsibilities and duties. Including facilitation of Scrum events, removing impediment within the team, and most of all staying vigilant to the agile values and principles (i.e. collaboration, transparent with work, and continuous improvement). It is always a rewarding moment when somebody you have coached starts passionately taking on the Scrum Master role.
Advice for Scrum Masters:
Give the team goal posts, create a Definition of Awesome with the team. This includes honestly reviewing where they are now, where they want to be, and defining a set of measures/metrics and a plan to get there. Examples of target areas are better team collaboration, reduce dependencies, and involving the end-user/customer in the development process. The definition of awesome must regularly be reviewed and updated as the team improves. (see Improvement Theme)
Push the team to grow and give them opportunities to step up. Increase the responsibilities of team members (i.e. ownership of team retro actions & tasks), cross-skilling opportunities and challenge them to experiment with new ideas. It is essential to allow these to occur in an environment where is it safe to fail. The team will quickly build new capabilities, resilience and confidence.
Protect the culture; Culture is the way people think, act and interact. An agile culture is something I first experienced seven years ago and am now addicted to it. For me it changed the way I think about work, it is make me excited to come to work, voluntarily stay late, and build lifetime friendships. Creating such a culture doesn't happen with a single work event or a lengthy management email. It is a series of decisions and conscience behaviours by leaders within the organisation. When something threaten the culture, it must be addressed immediately. Ignoring, avoiding or hiding the threat will validate it. Below are examples of how to destroy a great culture.
Trust - A lack of transparency will very quickly create a culture of knowledge hoarding and silos.
Innovative - This is quickly & easily destroyed by creating rules & policies which punish the 99%. E.g. a zero tolerance for mistakes.
Rewarding individual instead of teams - If an individual is rewarded for work completed by a whole team, what do you think will happen in the next sprint...
The time and attention a team needs from their Scrum Master naturally decreases as they become more fluent in agile and can self-police. However, I think all teams no matter how experienced benefit significantly from regular coaching. Also taking away attention and coaching prematurely in a team's agile journey is detrimental to their development and success.
What do you think?
Do you agree? Do you have another response?
What other advice would you give?