Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
I've been reading about agile methodology and while discussing it with colleagues the question of interchangeability of roles came up.
The scrum-master role is not an easy burden, so some proposed to do a bi-weekly rotation over all team members.
Wouldn't that contradict the specificity of that role and what it entails?
Our company went "agile" about 4 years ago and we've been constantly adjust/trying things that could work better than existing stuff.
I'm not claiming that this is 100% (or even 50%) correct answer, but In my experience, a scrum master, should be a dedicated person. At a minimum, it should be a person that WANTS to be the scrum master. If there are two people on a team who enjoy that kind of stuff, by all means, maybe they can rotate within each other, but I believe making the entire team rotate is not a good idea.
Being a scrum master (SM) is a completely different role, than being a technical team lead (TL) which is a different role than being regular developer and it takes different personalities to be good at each one. SM must stay on top of multiple issues which are constantly popping up. If management wants to change requirements or discuss yet another "special side project", SM should take ownership of these distractions and let the rest of the team focus on delivering the iteration. SM must also keep track of what each person is doing and coordinate effort between team members. TL's focus on much more technical stuff, but 25%-66% of their effort still goes into coordinating team member effort, but from technical point, not scheduling. Unlike SM and to lesser degree a TL, regular developers are not people who juggle other people's activities in their head. Instead, regular developer is happy and works best when he is isolated from external noise and is allowed to focus on details of the code that he is working on.
If regular developer is rotated into an SM role, he will be forced to pay attention to so many new things, that he will start losing track of the important details at the code level. At the same time, when he is rotated back, he will find code that was a) potentially done without knowledge of his details and b) it will take time for him to reacquire the lost level of detail that he possessed before switching his attention to schedules/people/issues.
Also people perform best when they enjoy what they do. If you take a developer that loves coding and make him attend all the SM meetings, a) he won't really be into paying attention and his interest will be in getting back to the code rather than coordinating team activities. In the past we had people who attempted to do both roles (manage and code) and at the end they failed at both. Now we have dedicated SMs, TLs and regular devs. I guess our team was lucky because we had two developers who actually prefer paperwork, meetings, leading and overseeing over coding, so they were happy to transition into their new roles. By HR standards, they are considered first-level management.
Vast majority of teams have the same person playing the role of Scrum Master each time as it's not that easy to play this role well. It's not without a reason. If a team has little experience with Scrum it's better to have just a single, more experienced person being kind of mentor. Also, as you point, that's not the easiest or the most intuitive place to be which is another point for having the same Scrum Master over and over again.
Rotation is sometimes proposed in teams where no one is willing to take responsibilities of Scrum Master. In teams which are familiar with Scrum and have decent experience working with the method it shouldn't be a big issue.
Note: that it is also pretty common thing to observe that teams which are fluent with Scrum need less support from Scrum Master as people collectively overtake some of Scrum Master tasks.
All in all, I would say that Scrum Master rotation can be useful in limited number of cases.
I heard a very good example from Mike Cohn during my ScrumMaster training. He believes and I would concur, that this role should indeed stay static. However, with everything, there are exceptions (e.g, if this is a brand new team, it might be worthwhile to rotate to find out who the best person suited for the position will be, etc.
However, in general, his metaphor was at home, his wife does the cooking. She is an excellent cook and has the skills to handle that role. He, however, does not have the same skills, nor do his daughters. If they would rotate out, often times, they would have toast for dinner.
Not every person is suited for the job of ScrumMaster and as mentioned above, I do believe this should be a dedicated role. By rotating a person in and out, you are also belittling the position.
