More and more organizations are implementing agile with Scrum. They define teams and assign Scrum masters to the teams to start working agile and become self-organized. Although agile looks easy, to implement the Scrum master role often turns out to be problematic. Let’s discuss what makes it so difficult to work with full-time Scrum masters and explore the alternative of having technical people taking the Scrum master role.
Dedicated full-time Scrum masters are hard to implement
Having dedicated full-time Scrum masters who have no other duties or (technical) role is the solution that is often chosen in larger organizations when they are transforming to agile. They are coming from a project management or other more “bureaucratic” management approach and really try to make the Scrum master role – servant leadership – work. But often it turns out to be hard.
My opinion is that the odds are against implementing dedicated full-time Scrum masters to increase agility. It often just doesn’t work, literally.
In larger, top-down bureaucratic organizations you usually start from a “command and control” culture. Based on what team members are used to they will view Scrum masters as a leader, a manager. They see the Scrum master who is “assigned” to their team as somebody at a hierarchical higher level as them, above them. This is how they have been managed all these years. So it’s no wonder that they will have serious doubts if it will be any different when their organization adopts agile.
Senior managers who do not deeply understand agile often have the view of the Scrum master as being a “manager”, a team leader. They want the Scrum master to be their connection to the team, the one person that they will work with, who will keep them informed. So instead of communicating and connecting to all team members, they prefer to work directly with the Scrum master. Give the Scrum master feedback. Ask Scrum masters to arrange things, ask for commitment, and expect them to get it done.
You can’t blame managers for having such expectations on the Scrum master role. This is how they have been taught to manage and lead. How they have been doing it all these years, what works for them, what has made them successful. So why would they expect it to be any different with agile?
For Scrum masters this is a difficult situation to work in. They are seen by the team and by senior management as “managers”. Senior management expects that Scrum masters coach teams and help them on their self organizing journey, but at the same time the Scrum master must keep everything under control. Senior managers are often holding Scrum masters responsible and accountable for the team result. Where agile suggests that they would focus on team learning and improvement, and teams are likely to make some mistakes and sometimes even fail along the way, manager expect things to improve from day 1.
With all these different expectations on the Scrum master role in organizations it’s hard to get it working properly. For the Scrum master it’s difficult to build trust, to get an open culture where people collaborate and learn.
In the end often nothing changes and the organization doesn’t reap the business benefits of agile. Having a technical team member taking the Scrum master role is a way to do real changes in organizations to increase their agility
Technical people taking the Scrum master role
My preference is that (technical) team members take the Scrum master role, in stead of working with full time assigned Scrum masters. They can do the Scrum master activities next to their regular technical activities.
When one of the team members takes the Scrum master role (s)he will be the one that supports and guides the team in their way of working and in the adoption of agile. Help team member in doing the agile practices that the team agreed to do. Remind team members, give feed, and coach them where needed.
There will be less resistance to this solution, acceptance by the team will be higher, since they can elect their own Scrum master. They can even rotate the Scrum master role, where different team members are the Scrum masters for consecutive sprints.
One advantage of switching the Scrum master is that during a sprint, the Scrum master can focus with the team on realizing the US from the ongoing sprint, while the scrum master for the next sprint gives extra attention on grooming the backlog with the product owner, and having good user stories when the next sprint starts.
For most teams there is no need for a full Scrum master role. A self organized team of 7 +/-2 people shouldn’t need 40 hours of management per week. Not even 20. You don’t want a Scrum master who manages three or more teams. It better to have the Scrum master as a part time role in the team, that way the Scrum master is always there when you need him/her.
Scrum masters can help their team members to solve impediments. They can coach team members in recognizing and addressing impediments, helping the team to self organize things. They do not have to be the one who is solving all impediments, and they should certainly not command team members on who should solve problems and how to solve them.
Do we really need Scrum masters?
Getting work done involves more than just doing the work itself. You have to communicate and come to an agreement with your customers on what to deliver. At regular times you need to check how things are progressing and if there is anything that is blocking the team. You need to coordinate with the team’s stakeholders. And it’s good to do agile retrospectives to reflect and learn. Scrum masters do these kind of activities, and they help team members in doing them. Which is useful to get the work done.
Earlier this year I interviewed Nic Ferrier for InfoQ in Making Agile Deliver Good Software, he mentioned that mature teams might not need Scrum masters anymore:
InfoQ: So there might be a need for Scrum masters initially when teams adopt agile ways of working, but in time they may become redundant?
Ferrier: That’s it, absolutely. And that’s one reason why agilists sometimes prefer Scrum masters to come from the team, to be technologists. Because then those people will naturally find a way to melt away their scrum mastering role. I think that doesn’t always work though. But that’s often because business managers won’t let technical teams develop in an agile manner.
What about facilitating the agile retrospective by team members who have a Scrum master role you might ask. Doesn’t that make it difficult for them to facilitate the meeting, since they also have a stake as a team member in how the work is being done? Yes it does, but an experienced Scrum manager is usualy able to facilitate the meeting and participate as a team member. When in doubt, it would be good to get somebody from outside the team, e.g. a Scrum master from another team, agile coach, or trained facilitator, to lead the retrospective.
How have you implemented the Scrum master role in your organization?
Do you have full-time dedicated Scrum masters? Or is it a role that is done by team members next to their technical activities? I’d like to hear from you!