The Daily Duties
“A problem a day keeps the Scrum Master away”, right?
I frequently hear that being a Scrum Master isn’t a full time job, especially on a single team. Organisations mitigate this risk of ‘under-loading’ in a variety of ways (only allocating 50% FTE to the role, adding multiple Scrum Teams onto their plate, or the worst option, removing it altogether) without an appreciation for the ‘Daily Duties’ of a Scrum Master.
I want to share a ‘day in the life’ of a Scrum Master to dispel some rumours that we are (and this is a direct quote) “stealing a living” or somehow becoming the modern day equivalent of a snake oil salesman!
Importantly, my day begins at the end of the previous one. I find that the accountability of a Scrum Master is misconstrued as the nominated meeting invitee, and therefore I review my calendar and politely decline anything I can’t add value to. I may get someone to attend instead of me, but mainly I’m trying to battle the ‘calendar fillers’ – I know I can’t be effective if more than 50% of my time is spent in meetings. Flex is king.
A typical day starts between 7-7:30am for me. I start early because it’s quiet. It gives me time to reply to emails and ‘walk’ the Scrum boards of the four teams I work with. I’m not viewing these to track them, but to ask the question ‘is their work and/or progress transparent to someone inspecting it’? If I started any later, I wouldn’t have time to do this peacefully before the barrage of questioning begins at around 9am.
When the teams come online, I’ll check in with them. Face time with every team is impossible, especially as I have four, but letting them know that I’m here if they need me is important at an ethical level. It might be a funny meme to start the day, a highlights message on the communal Teams channel or a reminder of upcoming workshops. Experience has taught me that whilst it’s easy to hoard knowledge to bring some sort of power, what’s the point? Unless you tell me a piece of information is confidential, please assume I’ll pass it onto the team. If flex is king, then transparency is queen.
Around 10 o’clock is when I will typically have my first meeting or Scrum event. Core meeting hours are powerful and respectful, and should be agreed amongst each team to account for flexible working. For example, my teams have agreed that 10-12:30 and 1-4 are when meetings can be held. I’ll try to dial into Daily Scrums whenever possible, facilitate Sprint Planning or Product Backlog Refinement when asked. Preparation for these events takes time too. It might not be visible to my teams or organisation, but believe me, it’s the iceberg effect. You might see 10% of the effort, but 90% is lurking under the surface.
With any duty that I perform as a Scrum Master I need to consider whether I’m supporting a self-managing team, or performing an activity they could do themselves. Over the long term, I’m not an effective servant-leader if I become a crutch that the team can’t live without. That’s why JIRA management, calendar organising, and minute taker is not something I’ll typically do. As a consultant, I’m not particularly cheap to have on your team, so consider what activities add value to your organisation – I’d almost place a bet that ‘JIRA’ isn’t one of them.
During lunch I’ll try and catch-up on the stakeholder emails that have come my way. There are always some that should have gone to the Product Owner or the Developers, but these are great opportunities to ‘coach via email’ – “Thanks for this information. John, the Product Owner is actually accountable for deciding whether this functionality aligns with our Product Goal – would you like me to facilitate an introduction?’. There is value in positive customer relations, and having the time in my day to reply courteously is important.
The afternoon is, again, spent facilitating or catching up with key stakeholders. In these cases, it’s very easy to over-step the line and become a Project Manager, being asked for progress updates on ‘your team’. If I had to pick one thing I hate about being a Scrum Master, it’s the ‘Master’ part – it implies hierarchy. Even though I may be considered a ‘Master of Scrum’, I’m not a master of the team, and referring to them as your/my team is implying I manage them. Even though engaging with stakeholders is considered an accountability of the Product Owner, I like to support this as I believe it helps with living the Scrum values and building trust.
As with all of discussions I’m involved in on a day-to-day basis, there are inevitably actions to follow up. I run a personal Kanban board so that I can monitor my flow of work. Perhaps it would help you too? In my experience, if you ever do get challenged on whether you are a value-add or a value-cost, you can show them your board and get them involved in its refinement. “If you can you help me by pointing out some things you can take off my plate, that would be awesome, thanks!”
Writing a ‘day in the life’ of a Scrum Master is hard. Everything you’ve read so far is vague, and that is because every day is different. Here are some activities I’ve missed out:
- coaching the organisation to stop making commitments to customers on behalf of my teams without consulting them.
- working with the Product Owner to define a Product Goal, order a Product Backlog effectively, or often, just what he/she is accountable for.
- attempting to upskill myself through reading articles, engaging in webinars and workshops or attending formal training.
- doing a gemba walk around my teams and our customers.
- …and the inevitable…helping to deal with ‘THE APPLICATION IS ON FIRE!’ moments.
So that’s my day done…if you can tell me where I could also fit in helping the organisation to remove impediments, running complementary workshops and all of the other things Scrum Masters are involved in, I’d love to hear from you.
If anyone tells you differently, do what I did once. Take two weeks off. You’ll either come back to a team who self-managed without you (a win for you as the Scrum Master) or a Product Owner with their hair on fire (a definite reason you’re needed).