One question I’m asked all the time during Agile and DevOps training and coaching is ‘what does the Scrum Master do all day?’. Misconceptions about the role are rife. Some people think they’re accountable for everything, others think they’re accountable for nothing. In the worst cases, they’re considered the team dogsbody, in charge of booking meetings, making coffee and writing up notes.
In fact, the Scrum Master plays the vital role of motivator and facilitator, enabling the team to operate seamlessly and effectively. This goes far beyond the daily stand up. They have to keep the team focused on long term goals while navigating immediate priorities and impediments. Doing the job well requires a good depth and breadth of technical knowledge as well as excellent interpersonal, communication and problem-solving skills.
So, what happens after the daily stand-up? I asked DevOpsGroup Scrum Master Charlotte Williams to talk us through a typical working day.
A day in the life of a Scrum Master
9.00 Coffee and a chat
I make my way up to the 22nd floor of Capital Tower, grab a coffee and take a moment to enjoy the awesome views we have across Cardiff before logging on to my emails and Slack.
There’s usually some good chat going on between our office based and remote workers about what’s happening in our lives and whether we made it to the gym last night. I also have an informal discussion with my scrum team about any successes or challenges encountered the day before. We get the catching up out of the way early, so the scrum teams are ready to focus on their daily stand-ups and start work.
9.30 The daily stand-up
This is the most important part of the day, so we have to use it wisely! My scrum team knows the routine – everyone briefly updates the group on their progress towards the sprint goal and highlights any issues slowing them down. We need to keep it concise and pacey, so I ask ‘what did you achieve yesterday?’ not ‘what did you do yesterday?’.
I’m not the boss of the team – I don’t have any authority over what they do or how they do it. I just need to keep a finger on the pulse of how the sprint is progressing, so that any blockers can be resolved before they escalate.
Today, one of our engineers has an issue with her machine and another has discovered he can’t proceed with a job because he doesn’t have the relevant permissions for the environment. They decide to pair-up with teammates on other tasks that need to be completed by the end of the day.
I tend to focus on the work flowing through the board rather than the individuals responsible for it. This allows the team to collaborate over potential impediments and prioritise their own work to deliver maximum value. I find this approach motivates the team and enables them to get all the information they need for the day quickly. We use a timer so we don’t go beyond the 15-minute timebox, but we like to wrap-up inside 10 minutes if we can.
We finish 20 minutes before my next meeting, so I pop round to ask the IT team to get a replacement laptop sorted. Then I Slack the management team to request access to the environment that the engineer couldn’t reach.
10.00 Scrum of scrums
When we’ve acted on any immediate needs identified in the daily stand-ups, Scrum Masters across shared products get together for the scrum of scrums. This is an opportunity to take a big picture view of progress and flag any impediments that may have repercussions for each other’s teams.
I’m confident that the issues facing my two engineers will be resolved today and won’t have any wider impact. However, one of the Scrum Masters is concerned that a problematic piece of codebase is slowing his team’s progress this sprint. We document this and agree to revisit it tomorrow.
Once this is wrapped up, I check back with my team and see that a replacement laptop has been set up, so at least one of the redeployed engineers has returned to her original backlog.
11.00 Weekly backlog review
This is the day for my regular backlog review with the scrum team’s Product Owner. We set aside an hour, twice per sprint to identify high priority items and consider how they can be refined for the coming sprint.
I originally trained as an engineer, so I have a good understanding of how tasks can be broken down into manageable pieces. One piece of work that the Product Owner wants to push through quickly is more technically complex than it might appear. So, I explain the mechanics involved and we find a way to split it across the next two consecutive sprints.
During this session we also refer back to the product development roadmap and release plans. We know that a couple of team members have booked holiday around the Easter break, so we adjust the list of high priority items to account for that and feed this back to the team. While the engineers need to focus on their individual backlogs day-to-day, it’s important for them to see how the team is progressing towards long-term goals. It also means people can relax and take well-deserved time off without feeling they’re leaving the team in the lurch.
It’s always good to hang out in the kitchen over lunchtime. I first came to DevOpsGroup as an intern in 2017, then joined permanently after I graduated the following year. Since then, I’ve moved from Engineer to Scrum Master, so I’ve worked directly with a lot of the guys here. We have a really dynamic and supportive culture, and there’s always someone to catch up with over a sandwich. I head outside for a bit of fresh air, then come back ready to see what the afternoon will bring.
13.00 Ad hoc team catch up
I get back to my desk to find that the environment access issues facing one of our engineers have been resolved, so everyone is back on track. It sounds like the morning’s pairing up has brought a couple of developments to conclusion earlier than scheduled too. Overall, the team is still on target, everyone is settled into the rhythm of the day and there are no issues needing my attention.
I take advantage of a bit of slow time to get things organised for our next sprint meeting in a couple of days. I book a room for the seven of us, and pull together all the resources we’ll need for the demo, retrospective and planning – there’s nothing worse than running out of Post-its or whiteboard markers when you need them most.
14.00 Agile coaching
This afternoon I’ve set aside a couple of hours for Agile coaching with the finance team. This is one of the most rewarding parts of my job, helping the wider business and non-technical people realise the benefits of DevOps and Agile ways of working. It’s great to see how simple changes can make radical differences to the working day, so people have more time to focus on interesting work instead of being bogged down by manual processes.
The finance team has been implementing Agile practices to improve workflow and efficiency, but there have been a few teething problems. One challenge has been visualising the workflow for raising and paying invoices. Last week I helped them address this using the tried-and-tested whiteboard and Post-its approach. We run through progress and they all seem far more confident than they did a week ago. Everyone is satisfied with the outcome, and we agree to replicate the approach across more processes.
16.00 Review the burndown chart
Back at my desk, I check the scrum team’s progress updates on our online tracking software and feel relieved that we haven’t lost too much time following the morning’s impediments. I plot the day’s actions onto the burnout chart, and it’s looking pretty good. Work in progress levels are a little high though, so I make a note to raise this during the retrospective in a few days’ time.
17.00 Home time!
Before we all head off for the evening, I whip round the team to check everyone’s had a good day. I let them know we’re on track with progress for the sprint, despite the issues raised in the stand-up. I do a final a check to ensure all the boards and tickets are up-to-date and that’s another day done!
Interested in our BCS Certificate in Agile Scrum Master course?