Scrum Master: Shared or Dedicated
During my last 5 years working as an agile person I’ve come across different types of facilitators in a Scrum environment, and I’ve even filled some of these roles. I’m going to take a look at 6 different types of Scrum Masters and how shared or dedicated they are with their teams. I’m sure there are many more other situations, but I’ve experienced these ‘in the wilderness’. For each type of Scrum Master I’ll go through the pros and cons of that position and make a recommendation. I’ve ordered them by the frequency I observed, which might not be the same as yours. Before I jump into the types of shared facilitators, however, I’d like to take a brief moment to talk about teams.
Team
Not every type of facilitator works with every type of team at any stage of development. A very popular and one of my favourite structures for team maturity is the Tuckman model.
In the Forming stage, everyone in the team is polite to each other. Nobody really knows anyone and social conduct trains us to not question the status quo.
Once the people have gotten more accustomed to each other, Storming is inevitable — this is the moment where conflict can appear, and it’s really healthy for it to happen. In this way the team can absorb new knowledge and points of view.
In order to get out of Storming, some new rules of conduct emerge. This can either be done with a facilitator, or a certain kind of conduct prevails over others. The moment the team has these rules and acts accordingly you can consider them in Norming.
The last stage of development in this model is Performing. At this stage the team has internalised the norms(or rules), has created an environment where it thrives and velocity increases but also stabilises. This is the purpose for any team.
While it is true that a team goes through this cycle multiple times, on a very core basis, without major disturbances to the team, it is more or less in only one of these stages at a given moment.
Now let’s see how different teams and different facilitators interact.
Product Developer and Scrum Master
This is the first position I ever worked in. While it wasn’t ideal from any point of view, it went smoother than other available options at the time. Looking back I can see numerous failures, but also some strengths.
Pros
- Only one context and one purpose — When acting as both Scrum Master and developer in the same team, there is a clear focus.
- Deep product and team understanding — Being both part of the team and working on the product leads to this.
- Can solve technical impediments — A big part of a facilitators job is to help the team move past impediments, in the case of technical impediments, hard knowledge about the product and how it is developed can make a huge difference.
- Increases leadership skills — When the team takes ownership of their processes through one of their own, as opposed to an external, leadership skills need to emerge in order to keep up with necessary changes.
- ? I’ve surely missed something, comment bellow!
Cons
- Cannot both facilitate and share their developer opinion — When facilitating meetings or other discussions/workshops, it becomes hard to share your own opinion and knowledge from a development perspective. If you try and do both, you’re probably not doing both good, and there is also a higher weight on the facilitators voice as opposed to the team mates.
- Development takes priority — As much as we would like to avoid it, it happens. Development is much more practical and has clearer results which makes the priority of urgent topics skyrocket as opposed to coaching the team on long term improvements.
- Must coach herself — It’s hard to see the forest from the trees when you’re so fully involved in the product.
- Might decrease servant leadership — While taking over the facilitator role on top of the product development one can increase the leadership of the Scrum Master, it could also lead to a decreased servant leadership. Are you there to help the team meet it’s ambitious goal, or are you there to lead them to it?
- ? I’ve surely missed something, comment bellow!
OK for
I would recommend this type of shared Scrum Master to teams that have been working together for a while and there is interest in switching to Scrum/Agile, but there is a high resistance to change. In cases like this, outside support is not easily accepted, and the initiative might be destined to fail. In Metro Systems we used this approach when transforming the organisation. After the resistance to change decreases you can either have the facilitator go full time in Agile, introduce another Scrum Master, or, if everything works well for them, why change?
It’s also nice to see somebody from the team step up when the Scrum Master is not available(short or long term), but in cases like these, I’ve seen only minimum responsibilities being covered and not the full spectrum.
Dedicated Scrum Master
After working with several teams, I focused for a year on a single complicated team. I think it’s the time where I learned most about team dynamics and what is needed to actually succeed with your product.
Pros
- Only one context and one purpose.
- Deep product and team understanding — When working as a full time Scrum Master with one team, and especially if you have a technical background and transparency on all team communication, you cannot help but understand the product, and this helps you communicate better with the team.
- Increased impartiality regarding technical and business implementation — Since you’re not fulfilling a double role inside the team, you can let the actual experts do their job without your opinion. They know best the technical product and the client, so you can focus on their process.
- Can coach entire team — As an observer of the big picture, the Scrum Master can assess what type of skills and approaches are needed in order for the team to deliver successfully.
- Full focus on methodology — No other distractions.
- Can focus on her own agile development in order to support team better — The agile world is evolving almost as fast as development these days! It’s not like you can take a 2 day course on being a Scrum Master, get your certification and Voila! that’s it. The most successful Scrum Masters I know give themselves between 10 and 20% of their time on keeping up with new practices.
- ? I’ve surely missed something, comment bellow!
Cons
- Can get too involved in tasks, decreasing team autonomy — When a facilitator’s single job is one team, it’s easy to start taking over tasks and not giving them back — just remember, the purpose is for the team to not need a Scrum Master anymore, so they need to take ownership of their process. (ex: facilitating review meetings, documenting decisions, planning meetings in calendar, etc.)
- Team could not support the rhythm of change enabled by full focus — Seeing the full picture, and having the drive to improve it, might mean a big list of actions that the team needs to take. As long as the team is not overwhelmed, all is good, otherwise change fatigue appears.
- ? I’ve surely missed something, comment bellow!
OK for
The newer or more problematic the team, the more support is needed. A full time Scrum Master can make a great difference at the beginning of a project, as she can help set healthy working habits inside the team and help them get to high performance faster. For teams that have already found their rhythm, that deliver constant value, this type of facilitator might be too much.
Scrum Master shared between 2 or 3 teams
While the original version of this article went up to 5 teams, as I’ve seen and felt it happen, that type of multitasking is not sustainable and should be avoided in all cases. Working with 2 or 3 teams, however, might be quite enjoyable for all.
Pros
- Multiple contexts increase rhythm of learning — Really good for developing the tool set of a Scrum Master
- Can focus on her own agile development in order to support teams better
- Focus on methodology only
- Increased impartiality regarding technical and business implementation
- Can coach entire team
- Can become a bridge that connects the teams — If the teams that are being supported have dependencies to each other, the Scrum Master becomes a subtle but efficient liaison between the two so at least the practices are aligned, if nothing more.
- ? I’ve surely missed something, comment bellow!
Cons
- Split context and focus will lead to delays — If in a dedicated role the team cannot keep up with the facilitator, then in a shared role it might be the other way around.
- Possible conflict of priorities — If all teams are on the same place, how do you deal with conflicting appointments? Other types of conflicts can arise. As long as you set a priority between them, and they are not on the same place, decisions are faster and the results are aligned to the company’s direction.
- Lower possible product and team understanding — When the teams are not in the same area, the constant context switching will decrease the level of understanding a Scrum Master can reach on both the team and product side.
- Can run out of time for self improvement — We tend to leave studying on the last place, when there’s nothing urgent ‘screaming’ at us. When working with multiple teams, there is always something urgent, so self development takes a step back. Planning for it can help ensure it’s still there.
- ? I’ve surely missed something, comment bellow!
Ok for
When the norms of the team have settled and the team is performing, working on another challenge might be just the right thing for a Scrum Master. This way the teams always have a coach that takes care of their development needs, without being too overbearing. Problems are rare, so when they arise it’s more likely that they will be the priority.
Agile Coach (Workshop & Training Sessions)
This is the situation I find myself right now, and a few times over the year. In this scenario, the teams no longer have a Scrum Master that is part of the team, but rather an external consultant that works with them regularly or on specific topics. While I’m not part of any specific team, it seems to be the position from which I can make the biggest difference. This type of work, however, requires a specific context.
Pros
- Multiple contexts increase rhythm of learning — In this position, one can even focus on a topic (like product ownership) rather than a team, which yields a far better evolution rate.
- Increased maturity and skills on mindset and methodology — As a conclusion to the increased rhythm of learning.
- Full impartiality regarding technical and business implementation — When all the coach does is to check in with the team regarding their progress and help them when needed, the need to go into details like these vanishes.
- Can coach for most/all occasions.
- Increased servant leadership — While the Scrum Master is involved in the context of the team, the coach is there just to serve the team itself.
- ? I’ve surely missed something, comment bellow!
Cons
- Full split of context leads to local improvement —At this point either the picture is too high level or it is not complete. Working on requests and/or based on minimum interactions with the team, means that the biggest problem in the system might not be addressed.
- No accountability or responsibility on long term results — In the role of consultant you are not connected to team strong enough to mediate a long term specific evolution. A general one can be obtained, one that is less anchored in the team context.
- No product or team understanding — Only the minimum required to find and solve the next challenge.
- No day to day coaching and problem prioritisation — If the team dynamics are not in the ‘agile green zone’, day to day small reminders are needed. In the case of agile consulting, it is not the agile coach who decides on the biggest problems in the team, but rather the team itself.
- ? I’ve surely missed something, comment bellow!
Ok for
Just to be clear, I’m talking about continuous agile coaching, and not once per year. If the teams are performing, they are fully autonomous, their stakeholders are happy and their internal dynamics are healthy, then checking in with an Agile Coach every once in a while might be just what they need. When the team requires persistent attention to go over a bigger challenge or change, then some more support might be ideal.
Product Owner Master
This has been the most difficult one to observe. There’s teams that end up without a scrum master and because the Product Owner is most involved in the project, they somehow end up taking up the responsibilities of a Scrum Master as well.
Pros
- Deep product understanding — They are the owner after all.
- …less people to pay/think about? — In case of lack of budget I guess this would be a plus
- ? This time I’m really curious if you see anything else, cause I really don’t
Cons
- Cannot both challenge the team and moderate the team efforts — How could someone who’s job is to inspire the team to reach newer heights every day also moderate in a neutral way the conflicts and overall discussion of the team
- Too much authority on one person makes her voice much stronger than anyone else in the room — Now imagine if they also have technical skills and opinions… Who from the development team will stand up against that? The worse part is, most of the people inside the team don’t even notice this inequality on a day to day basis, making it an even harder to change. Feedback in this cases becomes hard to get and implement, the team also moves with the speed on the Owner Master.
- Cannot coach herself — Improvement comes with outside feedback(faster one anyhow), who would provide this as the development team focuses on their sprint backlog?
- Not enough time to focus on product success and client communication — Both of these jobs are stressful and tiring. Most Product Owners I’ve seen in this situation have all but abandoned long term strategy and successful stakeholder management. It’s easy to focus on what you have next to you — the team, as opposed to an intangible future — product vision.
- Split purposes — Multitasking is the productivity killer. Dual purposes ensures reduced success in both.
- ?I’m sure I’ve missed a bunch, comment your favourites!
Ok for
Nothing. Just don’t…
Team rotation
This type of organisations appears in maturer teams I would say. When you’re not adhering to the scrum process, it also happens that the tasks are either spread or rotated between the team members, most of the time excluding the Product Owner.
Pros
- One context.
- Deep product and team understanding.
- Can solve technical impediments — Even though at this level the team self organises to solve impediments on its own.
- Increases leadership skills and responsibilities — Across the whole team.
- Minimal context switching can help with lateral innovation — If one misses something, others may not. It’s also fun to step out of your day to day role every once in a while.
- ? I’ve surely missed something, comment bellow!
Cons
- When in Scrum Master role, cannot neutrally moderate(or share developer opinion) — Even more since the facilitator role is not a constant, the need to share the opinion as a developer overwhelms the moderator role.
- Development takes precedence — Since the development tasks are constant, and this is just for a couple of days/weeks, priorities are mostly set on the tangible job — developing the product, not the team.
- Focus on own agile evolution decreased as opposed to a full time Scrum Master — Even though the whole team evolves in this direction, at a smaller rhythm.
- Lack of continuity — If bigger ‘projects’ are required in order to evolve the team, a lack of continuity between the people responsible to fulfil them leads to problems in accountability, speed, big picture understanding, long term improvement, etc.
- Process overview missing — In most cases, specific tasks are rotated, like facilitating the daily, retrospective, etc. A lot of the team development tasks are overlooked and might be missed.
- No third opinion.
- ? I’ve surely missed something, comment bellow!
Ok for
While the team can perfectly function and deliver value in this type of formation, help from an external person can bring them the insights they might be missing.
Conclusion
There’s a lot of variations of the Scrum Master out there, but one thing is for certain, the need for someone to look over the processes of a team and evolve them is here to stay. If it’s done better or worse it’s still an important part of the team that will evolve with our understanding of the agile mindset.
