The ScrumMaster role is key to a successful Scrum team – in fact, for any team doing knowledge work, a hands-on, full time role charged with building the capability of the team, empowering it to make its own decisions and optimise its effectiveness, and help it ‘gel’ is a great asset. Like a coach to a football team, the ScrumMaster can become critical in developing the full capability of the team so they can do great work.
Qualities of a ScrumMaster:
The ScrumMaster is often described as a Servant-Leader – there to help the team develop their effectiveness over the long term. Rather than orchestrating the teams actions directly to achieve a goal (as might a project manager – management by objective), the ScrumMaster develops the capability of the team, helps them identify challenges/goals, and ‘oils the wheels’ to ensure good information flow and teamwork – enabling the team achieve their objectives themselves (management by capability). So although the ScrumMaster indirectly influences the success of the team and the work they do, they are not directly accountable for success or failure – that is shared across the entire Scrum team – Developers, PO and SM.
Here are some attributes a ScrumMaster should exhibit (adapted from Mike Cohn):
Responsible – taking responsibility for developing the capability of the team, and finding ways to guide it through the Forming, Storming, Norming, Performing stages. This responsibility, however, does not come with the authority to tell people what to do.
Humble: A ScrumMaster shouldn’t be in it for the personal glory/status. Their job is to make the team look good, and themselves only as part of that team. They should also be humble in terms of working with the team to find new ways of improving effectiveness, rather than imposing their version of how the team should work (excepting the mandatory constraints of Scrum). As an aside, I personally think Humble is an attribute we should all value and exhibit – it is the first key ingredient of people who want to learn. If you aren’t humble then you may think you know it all – not a good starting point for continuous learning which is key to staying relevant and effective.
Collaborative: By words and actions, developing a safe, collaborative culture in the team. Encouraging people to learn from each other, not compete. The SM shouldn’t need to be a referee – referees are only needed where people on the team are competing/arguing and one party needs to be right and the other wrong. The SM should aim for light touch or no touch in the day to day operation of the team. The scrum events are for the team, not for the SM – they only get involved to ensure they are effective meetings. Instead they need to show the team the tools they need to self organise, and develop a sense of joint accountability for results.
Committed: The ScrumMaster must show leadership by being totally committed to Scrum and the Team they are developing/coaching. Even if it is a part-time job, it should be no 1 priority.
Influential – able to get the team to try new tools and meet new challenges without telling them they must do it
Knowledgable: The SM should have in-depth understanding of agile concepts and Scrum, and be able to articulate them. But they should also know enough about what the team does (technology, customers, etc) to understand what they are saying, help them identify challenges/shortcomings, develop key capabilities, etc.
There are also different views of how senior/junior the SM should be. A senior person may have implicit ‘authority’ over the team (even if not expressed) and the team may struggle to take ownership/responsibility themselves, looking to the senior SM to make hard decisions, smooth over cracks, etc. But a junior person, while avoiding this, may not be perceptive to the teams challenges, may not have authority to get the team resources they need, etc. I think the best balance is a true ‘peer’ of others on the team – but this mightn’t be possible always.
Another topic is – how should a ScrumMaster be selected? By ‘management’ or by the team themselves? Should a rugby team choose their own coach? I think this depends on the maturity of the team, and its members. More mature teams may have developed ways to reach consensus on difficult topics like these. They may have developed a sense of what challenges them, and where they want to develop. They may then be in a position to identify the person that would best help them achieve their goals. But I think this would be a stretch for a team starting out, or where the team has not ‘gelled’. In this case, I think an agile coach or management should involve the team in the decision, take on board their views, get buy-in – even if they don’t leave the decision entirely to the team themselves.
Also, you need to consider is how the ScrumMaster role might change over time – adaptive leadership. While the ScrumMaster might adopt a ‘directive’ style early in the teams life (telling them how to do it), they may move to more coaching, supporting and delegating styles at different stages of the team lifecycle. Search for articles on ‘Adaptive Leadership’ to get more details on this.
While Scrum does allow for a ScrumMaster to also be part of the development team, performing work on the product (coding, testing, designing, etc) its important that the role isn’t ‘diluted’ so much that it becomes second or third priority for the person concerned. While teams that are merely ‘doing agile’ – i.e. going through the motions of scrum events, etc may not feel the ScrumMaster role is significant, I find more mature teams begin to see the real value of the role and tend to make it a full time, specialised skill within the team. A part-time, thinly spread ScrumMaster role can indicate an organisation that is not investing in its long term capability – it is paying lip service to Scrum in the interests of appearing progressive while not truly transforming into an agile organisation where everyone is invested and engaged in maximising value production.
Personal experience:
In some organisations, project managers are seen as peers to the development teams – and here, if they can make the fundamental shift from ‘I’m responsible for the project’ to ‘I’m responsible for building team capability so they can be responsible for the project’ then I’ve seen them become good ScrumMasters. Also, senior technical folks, where their personal style is inclusive, mentoring, participative, can do very well (they tend to be respected for their competence rather than organisational position). Twice in my experience, companies have rotated the roll – I wouldn’t advise it as a long term strategy, though they did eventually settle on a team member that worked well – so maybe allow a few people try it out before settling on someone.
The best ScrumMasters I’ve come across tend to be ‘nurturing’ type people, but no push-overs – i.e. they need to be determined to make Scrum work, the way its meant to work. Ideally, they are respected and others will want to support them in making Scrum successful.
