Let’s talk a bit about different approaches to the Scrum Master role. The most common of them are:
- 50% Scrum Master of one team, 50% Dev Team member.
- 100% Scrum Master of two teams (50% each team).
- 100% Scrum Master of one team.
I will guide you through all three approaches the same way I went through them during my career as a Scrum Master.
Scrum Master and team member
That was the first approach I worked with. I was a Scrum Master and a Dev Team Member at the same time, doing mostly business analysis and some testing. It was pretty cool – I had great and natural insight into what was going on inside the team and it was also very easy for me to integrate with the team and build trust.
After few teams and projects I realized though that being both Scrum Master and Dev Team Member split my personality. During all my activity I needed to highlight to the team when I was acting as a Team Member and when as a Scrum Master. It also created a belief inside the team that I was the ‘do-everything-guy’ and made them strongly dependent on my presence. It was natural that all impediments were resolved by me. I realized that despite having great insight what is going inside the team, I was at the same time strongly biased.
Scrum Master for two teams
On some next project I was Scrum Master for two teams. I appreciated unbiased view, free of influence of daily team tasks. Finally I have had an opportunity to observe the team without being involved into their work. I also had more time to start working with Product Owner, supporting him and facilitating tensions between PO and the Dev Team. Previously I was a part of these tensions and as 100% Scrum Master I was just facilitating them. All good changes.
There was also other side of the coin though. I wasn’t so close with the team as before. Unbiased observation cost me relations with people. Working with two teams at the same time makes it even harder to talk with everyone. There were also many other challenges like: Where to sit – with team A or team B? Not always there is a place in between them. How to plan Scrum events, especially when teams would like to be aligned with Sprint start dates? Should I go for team A’s or team B’s planning? Constant logistical challenge.
Scrum Master for one team
After gaining experience with those two models I started to dig a bit more. Someone on some training or conference said: “Good Scrum Master can handle two teams. Great one, only one.”. It resonated in my head and forced me to think. I went back to the Scrum Guide (I constantly come back to it, couple of times per year and believe me, you can always find something new there). What I learned was that Scrum Master should serve on three areas: Dev Team, Product Owner and Organization. I realized that in two previous approaches I was serving the Dev Team, that’s obvious. Sometimes I was even serving – just a bit, but still – to the Product Owner, but I’ve never touched organization area. I just had no time for it.
The only way to cover all three areas is being Scrum Master for only one team. It’s the below chart taken from LeSS (less.works) that helped me to understand how this works and why at the beginning I felt comfortable working with the first two approaches.
For easier analysis I will consider Organization and Development Practices as one line. When you start up a new team, fresh to Scrum practices, you need to spend huge amount of time with them and with Product Owner. The only things you need from your organization are trust and patience. When the Scrum Team becomes more mature, they will notice some boundaries and impediments within the organization, also some processes, tools or just culture which is against them, and that prevents from accelerating and mastering development work. In this moment Scrum Master should start to change his focus – while still being available for the Development Team and Product Owner, he or she should invest more and more time into organization area, trying to stimulate changes which will help the Scrum Team being more efficient.
In the first two discussed approaches the Scrum Master will never have enough time to work properly with organization. Were they bad though? Scrum idealists would say – hell yeah! But let me present the context of that projects – I was involved into 3-4 months lasting implementation projects, being done with new Scrum teams, with people who never worked in any agile methodologies before and with the assumption that after the go-life those teams will be scattered between other projects. Taking this into consideration the response is not so obvious. Comparing to the graph above, with these teams I would never get to the point where I would need to refocus on organization. Furthermore no one expected me to do so, because I was involved into implementation projects only and the organization itself didn’t want to change. They just wanted to have a new IT system implemented, not the agile transformation done.
I strongly believe that each presented approach can be ‘the best one’ depending on the context. Most important is to understand consequences of each and pick one consciously. Thinking of You – which approach is used in your organization and what is your experience with them?
I agree with most (if not all) of the statements from your article. However, I believe this is a simplification, as lots depends on the situation, timing, people. With some teams you need to spend a lot of time, with some not. At some point you can (or you should be able to) start helping second team without much damage as first becomes more self-organising and needs support occasionally.
There is also a temporary/emergency team member situation, when due to emergency situation Scrum Master has to become part-time QA for example. This has of course all the drawbacks of the SM being a part of the Team, but also gives you more direct ability to influence the Team, as your are a part of it.
Thanks for comment Karol! Helping Scrum Team in emergent situation (like you mentioned – being part-time Dev Team member) is also something which happened to me couple of times. I just wonder whether such approach is not a short-term gain burdened with huge risk and long-term loss. If you do this only occasionaly, how Dev Team should percive your role? Whether Sprint Goal may fail bacause you, as a Scrum Master, did not deliver analysis? What is the impact on transparency? You virtually increase team Capacity and you hide team problems with your engagement.
As you said – it all depends on the context. But nevertheless I would estimate such behaviour as much more risky than nominated half-time Scrum Master and half-time Dev Team memeber.