Failure Modes of the Scrum Master Rotation and How to Fix
We’ve being rotated Scrum Masters in the team for quite a long time （see Three Phases to Implement Scrum Master Rotation and More on the details on how the Scrum Master rotation is designed and implemented）everything runs well until in a recent Sprint when the Scrum Master of one of the Scrum teams asked a leave for several days.
The Scrum master did delegate his responsibility to the other person in the Scrum team, as required by team charter. However, he did not tell that team member that he should check and ensure that task status on the whiteboard should be synchronized with the same in the Rally. This issue was identified and reported as one of the problem in the Retrospective meeting. However, there’re more than one failures involved in this issue.
Firstly, as indicated by the problem itself the whiteboard was out of synchronization with the Rally which is the system that all user stories and tasks are being tracked in order to make the statistics easy, this problem causes confusion because the information reflected on the whiteboard is different from the Rally.
Secondly, in order to make the life of Scrum master a little bit easy, I’ve developed a Scrum master daily checklist, so that, in the daily standup, Scrum masters will go through every item on the checklist and make sure everything is in a good status. Everyone in the team is aware about the checklist, because it is printed out and put on the team whiteboard. Then why Rally was actually not checked even with the checklist clearly require the action? The possible reasons are:
1. The Scrum master who took the leave ignore it;
2. The delegated Scrum master ignore it;
3. Everybody in the Scrum team ignore it;
4. The checklist does not have focus, so that it would be very hard for people to follow;
Thirdly, if looking at the issue from a more extended view, every responsibilities that the Scrum master expected to take would be failed if he/she is leaving without the work being properly delegated. For example, the daily standup might not happen at the scheduled time, the whiteboard might not be updated, the retrospective might not be performed, team might not be aligned with the daily goal, and the like. This is definitely a big failure of the whole Scrum mechanism, because the Scrum master is such an important role to ensure every team activities are well taken and aligned.
It could be argued that the Scrum team should perform even with the absence of the Scrum master, since the team is self-organized. In my opinion, this is the very ideal situation when the self-organization maturity of the Scrum team has been evolved into a very high level. And we should take some actions to fix the problem and help with the evolvement.
The actions that we took after the retrospective meeting was to perform the Failure Mode and Effect Analysis (FMEA) on the absence of the Scrum master, with all the potential failures and mitigate measurements be identified. Below are the improvements the team and me started doing after that:
1. Simplified the Scrum master daily checklist
The first version of the Scrum master daily checklist has 20 items, which make it very hard and time consuming when go from the 1st item to the last item. I simplified the checklist from 20 to 6, so that everything would be checked within one minute. Checking and ensure the synchronization between whiteboard and Rally is still one important item in the simplified version.
2. Implemented the primary/secondary Scrum master mechanism
In the reliability engineering, one of the important design measurement is the duplicated design, where two modules implement the same functionalities and run at the same time, one services as the primary module and the other one as the secondary. The secondary module will take over the primary module if it failed. This same idea was implemented in the Scrum team, with the premises that firstly, everybody knows the Scrum development and has actual experience with the Scrum master, secondly there’s a fixed order of Scrum master rotation.
The diagram below illustrates the mechanism, assume there’re fiver members in the team. The basic rules are:
a. If member 1 takes leave, then member 2 will be the primary SM, member 3 the secondary SM;
b. If member 1 come back from the leave in less than 3 days, he/she will resume as the Primary SM, and member 2 resume back to secondary SM, member 3 the team member;
c. If member 1 come back from the leaver in more than 3 days, he/she will be the team member and lose the opportunity of being the primary SM. Member 2 and member 3 will continue to be the primary and secondary SM.
What I learnt from the whole process of analyzing the problem, performing FMEA and identifying the improvement actions are, firstly, simple things is easier to be followed than complicated ones; and secondly, FMEA analysis should be performed whenever we designed something, including team, process and product; thirdly, new problems are continue emerging every day, but those are good signals to indicate that we’re far from being perfect and there’re always opportunities for us to get better.