The distant ScrumMaster
Stefan 17. July 2015
I am back
First of all I need to apologize for not having written for so long. There’s always excuses for everything, so let’s just call it “prioritization”, which is something that we (agilists) do a lot. So I had to do myself. In the meantime though I have prepared some blog posts but I never got down to really publish it, which I will now do over the next few months. Let’s see how long I can keep up with it….
The first story I like to write about is about the “distant scrum master” and be warned as it is gonna be a very long blog post!
Most of us probably have an idea what a ScrumMaster should do. While this is nicely understood in a co-located team it is interesting what ideas people come up with when undertaking a Scrum approach in a distributed way. I have seen quite a few ideas how to set up teams but this one really astonished me. Before I really dive deeper into the topic, I like to mention that I really appreciate those people who are currently in the role of the ScrumMaster!
The setting I encountered
Imagine a development team that is not co-located with the Product Owner. Even though this is definitely not the intended way of doing scrum, this happens more often than we like it to be – you could question reality or rather find good solutions for it. So what happened and what is not seldom to find (though not ideal) is that Dev-teams are not co-located with their PO and therefore you would find something like that
Location 1 -> 100 miles away -> Location 2
PO Dev-Team
But what about the ScrumMaster? I don’t want to start the old question new whether the ScrumMaster is >part< of the Dev-Team or not but most of us are probably of the same opinion that the ScrumMaster works intensively with (and for) the team. So, what do you think of the following situation?
Location 1 -> 100 miles away -> Location 2
PO / ScrumMaster Dev-Team
Honestly I was pretty surprised because I hadn’t seen this kind of distribution of roles before. How should this work? How is the ScrumMaster able to deal with the team? I had seen situations before where the PO was distant but the “distant ScrumMaster” was new to me. Well, before we question this more, we should understand how the dev-teams work (it is actually not only one SM/PM/DEV = Scrum Team but we have several of them).
Each Scrum-Team runs on a same length sprint. At the end or beginning of the sprint (depending on how you perceive this) and on one day we undertake the sprint review, the retrospective and the planning. It should be noted here that the location at which the ceremonies take place is not always at the same location but it switches back and forth between location 1 (home location of the PO) and 2 (home location of the dev team) on every other sprint. That means the Scrum-Team meets on each of the sprints at alternating locations – sometimes the PO/SM travel, sometimes the whole dev team. Also they run dailies on a virtual basis using latest video conferencing techniques to make sure “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” is met. I am only mentioning this to show that the ScrumMasters are very engaged and motivated and thus manage the dailies efficiently, they prepare the retrospectives very creatively and run organized sprint demos in a very good way. They are really doing great (I mean that!)
Anything wrong with that?
Well, you could argue that unless everything works fine, there is nothing wrong with that. And, to their “defense”, many things actually work pretty well. They are well trained and motivated ScrumMasters and do the best they can. And that’s the point: They do the best they >can<. When I entered the scenario (on the dev team location) we were currently scaling up. Only a few months ago we had added a second team and were approaching the third team. No wonder, the teams were under a lot of storming influences (and we as company grew alike which added further stress to the environment). So there was a lot of storming (which brings along conflicts) that had to be taken care of. Enter the ScrumMaster! However, there is almost no way that a “distant ScrumMaster” can be aware of the team vibrations. Sure he (or she) talks with the team (via Skype or Webex) on a daily basis and they meet bi-weekly in person but the real personal behaviours and subtle gestures a team member does cannot be perceived from distance. It is even harder to solve those conflicts as people usually need a close relationship over weeks and months to build trust. So of course it is not their fault if they don’t notice conflicts nor is it easy for them to solve. They really tried but from my perspective even though they had some success they actually had no real chance to support efficiently.
The Scrum hardliner would probably say that the solution is easy: Just move the Product Owner, ScrumMaster and Dev Team to one location but of course in many situations this is just not that easy. We have a great team and great POs and SMs. Moving people lifes to one or the other location makes things worse and replacing one or the other with on-location people is not really what we want. So living by the Scrum book is not always an alternative.
Our solution?!
Like in any realistic scaling environment you have to think about pragmatic solutions knowing that everything we do is a compromise to the ideal situation. One option would have been to move the ScrumMaster to the dev team, where he actually belongs too but that’s as bad as moving the dev team because the Scrum Masters home location is in a different city and we care about work-life-balance a lot. Besides that those people take care about removing impediments at the clients side which is most efficient there and almost impossible from remote while being with the dev team. So moving is not an option.
Our proposal was actually to establish a local ScrumMaster. To no surprise this led to a lot of misunderstandings on the ScrumMaster side and hesitation because they felt it would question their work (and especially the fear their line manager would question why they would not be able to do their work as there would be now a “second ScrumMaster” at the dev team side). Honestly even bringing up the idea led to quite some “uproar”. It didn’t really make it better when we kind of stepped backed a bit by proposing to “just” add an Agile Coach on the dev team side who trains and coaches the team on self-organization, conflict management and self-improvement. The doubts on the ScrumMaster side prevailed. Anyway it was decided to try out the latter and give it try (Thanks for the trust!).
So we did. We established a coach with the idea to support the dev teams to mature and help establishing their self-organization. After some time more and more the “distant ScrumMasters” (from now on I like to call him the main ScrumMaster as this term is more esteeming) noticed that their work they had done until now was still highly appreciated which built trust into the new idea. What was still missing was
1) some dedicated space/place where the 3 teams could communicate about topics that were spanning the teams but even more important
2) a ceremony where they could talk about topics and conflicts that were not only related to the client but to their own company.
Hence, the team decided to run an internal retrospective that spans the whole teams before they would go into the single team retrospective that was run by the main ScrumMaster. Honestly again this lead to some degree of mistrust by the latter as they felt something was hidden from them and they were not really a trusted person. It took many months until he noticed that this is not the case. In fact the teams became even more open on their side while they were able to talk about internal affairs upfront. Even better the dev teams entered the single team retrospective very well prepared. If you would think that the team retrospective would now become just a replay of the internal retrospective you may be surprised to hear that this is not the case at all. The teams run the team retrospective as team related as before but adding spanning topics to it which adds a comprehensive view on the project and the team. Scaling is not about making one team better but all of the teams together.
All the above helped the teams a lot to move through the storming phase when they had to scale so quickly but still I felt that it would be nice if we could improve the teams even more.
I asked the teams and they came up with the idea to actually only now establish the internal ScrumMaster.
But why and why now? Let’s answer the second question first: Only now because it took months to build up trust with the main ScrumMasters that they understood that the team very much appreciates their work. But why: One reason is that the main ScrumMasters have a lot to do on their side to work on impediments and of course to take care of tasks at their location. So the idea was to establish ScrumMaster who organize only topics that have to be done during the sprints (this excludes explicitly all ceremonies like dailies, sprint planning and retros which are still undertaken by the main ScrumMasters!). They would look after the dev team only on their and support the main ScrumMasters.
From my perspective this really matured the team. The Proxy-ScrumMaster (PSM, if we want to call them like that) really enjoyed to become more responsible in supporting the team and familiarize with Scrum (we train them extensively) while it takes some burden from the main ScrumMasters shoulders. It also facilitates the communication between the colocated teams because PSMs communicate with each other (and with the main ScrumMaster) on a regular basis what’s going on in the team. Besides that they would automatically take over the leadership role of the main ScrumMaster if he would be absent which automatically mitigates the problem of the ScrumMaster being indispensable (which relates to every Role that is only appointed to one person) which even more counts cross functionality of the team.
One might doubt about the overhead that this concept would generate. Personally I think it is negligible but leads to a lot of nice improvements at the side of the distant dev team because finally you could actually ask who is distant: the PO and SM or the dev team?!
Summary
I am aware that this concept will always be under discussion, some people even think it is not really necessary (sometimes) and maybe someday we do not need it anymore or responsibilities will change. Anyways, during the time of growth it matures and supports the teams and also gives some of the team a way to grow on their social competencies. Agile is about trying out new ideas and do experiments, which is why I wanted to share this experiment to you.
And again: The distant/main scrum masters have always done and still do a great job!
- Uncategorized
- No comments