Towards the end of a recent contract I had a stint as team scrum master. I enjoyed it a lot. To me scrum mastering is largely equivalent to being an XP tracker. My job was to get stories and tasks moving. That generally involved raising team awareness of progress, identifying the bottlenecks and finding ways to fix them. In the longer term I would have been encouraging the team to find and fix these bottlenecks themselves.

I’ve been in a range of teams over the years, both good and bad. The thing that stood out most with the good teams was not the skill level of the developers on the team, though that helps, but that they were used to winning. A team that gets it (i.e. success) can storm through work. A team that is used to delays and failure gets comfortable with that, plodding along safe in the knowledge that at least the other teams are in a similar situation. The biggest factor in generating and maintaining a successful team is getting them to experience the rhythm of success. When people get used to that and get to appreciate it, they will actively participate in maintaining it (most anyway).

As scrum master or tracker the job is to help the team succeed. That means identifying the pain points or causes of failure early and fixing or mitigating them. Helping the team get through tasks quickly and correctly. A few pointers that seem to have worked well:

Speed up the review cycle - A significant cause of delay in getting stories complete (apart from external blockers) is the delay in waiting for review (and re-review). A developer or pair spend half a day on coding a task, then a couple of days for reviewers to get around to looking at their code, then maybe another day or two to get though the remaining review cycles to merge the code. Too slow.

Review of pull requests should take precedence over ongoing coding. If you’re deep in the logic of the task and don’t want to be distracted by context switching, fine - it can wait an hour. Let’s be honest though, how often do we write code that requires that level of focus? In my experience, not so much.

The other common argument is that if I’m spending so much time reviewing other people’s code, I’ll not get my own task finished. There are a couple of responses to that:

  • The tasks/stories belong to the team, not the individual developers. The code you’re reviewing belongs as much to you as the developer that picked up the coding task. The kudos for task and story completion goes to the team, not the individual. So you are being just as productive reviewing as coding.

  • Again from a team perspective, if there is one task in coding phase and another task in review phase, then the latter is closest to completion so should get priority (other critical path factors notwithstanding). When that task or story is done everyone can pile on the story you’ve picked up to code. It evens out.

Fewer stories in play - Related to that, team productivity appears to be higher if everyone gets into the habit of piling onto a few stories at a time, getting them done, demoed and accepted, before moving on to the next stories in the sprint. As opposed to everyone (or each pair) picking up their own stories then spending the sprint working on them. Getting the success of having stories accepted frequently during the sprint is a good feeling.

Frequent demos - On a similar note, it appears to work better if there are frequent, short acceptance demos (Business Analyst or Product Owner time allowing) as soon as stories reach a demoable state (i.e. are complete and are deployed to the correct UAT/staging platform). The alternative of having maybe weekly scheduled demos feels slower, and means the team have to wait for that story acceptance. Not as much fun.

When it comes to tracking and removing bottlenecks, it’s important to know the team members will either definitely come to you as soon as their progress starts slowing; or preferably, will immediately reach out to whoever can get them back up to speed when they hit that situation. If you don’t know your team members will all definitely do this, then it’s important to do the XP tracking role regularly and frequently (every couple of hours). Just do the rounds - for each team member, find out what they’re doing, how long it will take to complete, and whether they can see a clear path to completion. If the answer is anything along the lines of ‘I’m not sure’ or ‘It’ll be done when it’s done’ then there is an issue.

At this point, see if adding expertise from someone else will speed up the process. Either someone within the team or an expert resource outside the team. Set it up. If necessary, drag the expert to sit down beside the team member that could use a hand. If you’re in an environment where such requests take time (for example, emails take days or many reminders to get replies, or the expert in question rarely has time) expedite it by any means - bribery/horsetrading/escalation :) Whatever it takes to get your team member moving again.

This was probably the single biggest speedup to team throughput during my brief stint as scrum master.

Shared at https://www.linkedin.com/pulse/scrum-mastering-how-succeed-donal-stewart