Why dedicated Full-Time Scrum masters are hard to implement – and what’s the alternative

Scrum master from the teamMore 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!

About Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.
Tagged , , , , , , , , , . Bookmark the permalink.

10 Responses to Why dedicated Full-Time Scrum masters are hard to implement – and what’s the alternative

  1. Antoinette says:

    Ben, your article summarises my experience as Agile team member and as Agile coach really beautifully. Not everyone is happy with the angle that “real” Agile teams do not need scrum masters, but having access to an Agile coach a la Spotify rather than an in team SM works much better for mature teams.
    Thank you!

  2. BenLinders says:

    Thanks Antoinette for your reaction. Happy to see you confirming my suggested approach of having the SM role filled in by team members.

    Wrt coaching, here’s my take on that in agile needs coaching.

  3. Brian says:

    An interesting perspective. As someone who has worked under a number of different methods, I can quite honestly say that, whether or not the ScrumMaster is a dedicated person or a member of the team (technical or not), success is determined mostly by the culture, support, and maturity of the team/company. I certainly agree that any member of the team should be able to handle the administrative duties of the position — facilitating meetings, coordinating the removal of impediments, etc. However, the primary role of the SM is to be a coach and guide to the team on its agile journey. Many team members are not up to the task, either from a lack of experience or from a lack of the softer skill set needed for success in the position.

    While a very mature, self-organized agile team could quite easily not need a SM, only a skilled (not necessarily experienced) SM can guide/coach a team through their agile journey to get to that point.

    If you have team members that have that ability, that’s great, but the reality is that most places hire engineers based on technical skill and often not leadership qualities. What you end up trying to do is have people guide a team through a very non-technical concept that they are simply ill equipped for success. How many technical team members are skilled at conflict resolution? Steering conversations? Making certain that everyone is participating? Guiding the team towards transparency and open communication? Making institutional changes from a position of no authority? I know far more engineers that chose the field because they preferred working with computers over people, and those are not the types of people you want or need as a SM.

    The good news is that these skills can be taught, but you need someone to teach them, someone to nurture the teams as they grow. That’s where agile evangelists come in, or agile coaches. Often times though, they are the first ScrumMasters… which is a non-team member taking on the role, and that’s exactly what your article is cautioning against.

    To summarize, I’m not sure where I’m going with this other than to say, there is no best way other than the way that works for you and your organization, and what works today may be different than what you need tomorrow. Be agile and adapt.

    • BenLinders says:

      Thanks for your extensive reply Brian.

      The agile journey needs coaching to succeed, as I elaborated about in my blog “agile needs coaching”, no doubt about that.

      It is the culture change that this blog is aiming at. To change from a bureaucratic hierarchical command and control culture to a collaborative and result oriented culture. What I’ve seen is that when Scrum is introduced with full time, non technical, Scrum masters, this culture change doesn’t happen.

      It’s also about evolutionary vs revolutionary change. Often small evolutionary steps work best. But sometimes they just take too long to get real change done, where an larger disruptive step is needed. To make real impact in the culture that might be the best to do. But indeed, it depends on the company and where they want to go.

    • Adria says:

      Brian, I agree with you 100%. The administrative side of the SM role is much easier to implement, in my opinion, than the more important coaching aspect. That’s where a true, trained SM shines.

      • BenLinders says:

        I second that. It’s about helping people to do their job and get better in what they do. And building an organization which makes it all possible.

        One of my biggest worries is that many Scrum masters are only trained on the process, and not about what it takes to coach people and to help organizations to adapt.

  4. Wilson Zhang says:

    There is an old saying in China “Master Student learned, then the teacher starved to death”. But in fact, that is not true, teacher is necessary position in school since there are a steady stream of students coming to the school. If as a scrum master, you can coach the team to come into maturity. You can still find something new to improve the team’s productivity. Even there is no need for you to coach team in that company. You can find more opportunities outside to continue your work and life.

    • BenLinders says:

      Thanks for you comment Wilson!

      Yes, there will always be opportunities to coach, even in mature teams. Great soccer teams still have coaches.

      What can be different though is that in mature teams members can coach each other. So they will depend less on the Scrum master.

  5. Daniel says:

    Hi,
    while I fully agree that Scrum Masters recruited from former management roles can have and cause a hard time, I can’t see any or only poor relation of these to Scrum Masters working 100% and dedicated. I think the second is very desireable and an essential factor for fastly delivering and evolving teams.
    So I find the first headline(s) of the artivle quite missleading.

    Best Regards
    Daniel

    • BenLinders says:

      Hi Daniel,

      Although the situation is different when the Scrum master isn’t a former (project)manager, I still see many problems with full time Scrum masters.

      First, the question is what they will be doing, as I think helping a team as a servant leader doesn’t take full time. There’s risk of “over managing” the team, doing to much which impedes the team in becoming truly self organized.

      Second, the part of the Scrum master being perceived as a manager by management is often still true, even when the Scrum master doesn’t come from management.

      A team of professionals should be able to manage their own work. In my opinion mature teams don’t need a Scrum master. Less mature do need someone who coaches them and organizes things, but in my opinion it’s a part time role.

      Would love to hear your thoughts on this Daniel.

Leave a Reply

Your email address will not be published. Required fields are marked *

  • Ben Linders – Independent Consultant Agile, Lean, Quality, and Continuous Improvement

    Ben Linders
    Ik help organisaties om effectiever software te ontwikkelen. Neem contact op voor mijn diensten.

    I help organizations to effectively develop software. Contact me to hear about my services.