I have to admit that I was one of those people that used to think “what do Scrum Masters really do all day?” That was until I took the role on myself.
I’ve been working in and around Agile environments for around 11 years, mainly where Scrum was being used. In that time I have attended hundreds of Scrum Events and worked with others on 12 different Products, so I consider myself to be a seasoned Agile practitioner, even though I have never formally taken on the role of Scrum Master or Product Owner.
I recently joined a Digital Agency as a User Researcher, a role to help fill a gap in the team’s knowledge while the company recruited a permanent employee. However, soon after I joined, the Scrum Team’s Scrum Master left. Now, since I’d been giving my opinions on how we were working (having recently been an attendee on Red Tangerine’s Professional Scrum with Kanban class and excited about what Kanban can bring to Scrum and given my many years of working in Agile environments, they asked if I would take on the Scrum Master role for the team. I jumped at the chance. I knew about the Scrum Framework, I thought I knew about the Scrum Master role, I had a lot of experience working within the Scrum Framework so I thought, “yeah, of course, I could do this…”. I was excited to take on a different challenge, learn new things and have a break from my usual role. It turns out that I was in for quite a shock.
It was amongst the toughest few months of my career. Things that I had seen and knew worked elsewhere just didn’t click. I struggled in using influence to guide people when it felt it would have been easier to tell people what to do. And I started to see where ways of doing things were holding the team back. It suddenly seemed like there was a lot to do and add to that, I realised I was still learning about the Scrum Master role for real.
The place for me to start was of course how the Scrum Master role is described by Ken Schwaber and Jeff Sutherland in The Scrum Guide™. Ken and Jeff talk about the Scrum Master being “responsible for promoting Scrum,” being the “servant-leader for the Scrum Team,” helping “those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t,” not to mention the 17 bullet points on how the Scrum Master is supposed to serve the Product Owner, Development Team and the wider organisation. And as the Scrum Guide just explains the rules of Scrum, it didn’t really help me with what I should actually be doing in practice.
I started to reflect on the approach of past Scrum Masters that I’ve worked with. I’m fortunate to have worked with some great Scrum Masters. I remember one who did everything they could to support and accommodate the team’s needs, another that inspired the Scrum Team to experiment as much as possible, others that were great facilitators and at instilling discipline in sticking to the purpose and timeboxes of the Scrum Events, one that managed to change the behaviour of the CEO from constantly interrupting Sprints, to fitting their schedule around the team, and one that completely re-educated the Product Owner on how to properly manage the Product Backlog and set expectations with stakeholders. All of these Scrum Master approaches were something I could draw upon in my efforts with the Scrum team and organisation that I found myself in.
Instead of becoming the team “manager” I learned to observe. I’d be watching to see if the team held each other to account, for example by referring to the Definition of Done when finishing work items, or that they were following their own policies as set in their team charter. I wrestled with questions such as “what do I do if they are not?”, “when should I step in and raise this?” etc. These are things that I now understand come with experience.
The basics of Scrum were in place, so I started borrowing ideas from Kanban, from what I had learned on the PSK, but also ideas from when I did Kanban System Design. Together with the team we updated our virtual board to better visualise what was actually going on. We formalised policies on when and how work items can progress from one work state to the next. I started capturing cycle times and plotting a Cumulative Flow Diagram to see if these would give the team wider insights. An interesting experiment we tried was to change from having the Sprint Review, Retrospective and Planning all on the same day. The CFD showed that whereas previously things seemed to be stagnant for a couple of days after the “Event day,” changing to split these across days meant that there was a smoother flow of work and most interestingly, a reduction in our cycle time and improved throughput.
As I got more into the role, I found myself constantly thinking about wellbeing as well as team performance. As we were a fully remote team, I made time to catch up with team members as much as possible on slack or on a Zoom call, replacing the random opportunity to chat over the ‘water cooler’ or having the ability to go and get tea or coffee (hot chocolate in my case) together that we would have in an office.
I did my best to allow the team to focus on their work, while balancing getting them involved in the bigger picture. I’d attend meetings with the Product Owner and the stakeholders. I would sometimes spend so much time here on Product Vision, strategy and Product Backlog, that I would worry that I was not spending enough time with the team. On top of this, I was still supporting the team with my UX specialism, pairing with team members to facilitate user interviews, defining problems and ideating on solutions, or helping out the team wherever I could in other ways.
The whole experience was very overwhelming at times. When my contract was coming to an end, I had no tangible things to hand-over. I was used to taking my successors through all of my UX artifacts such as User Flows, Research Plans, Experience Roadmaps, Discussion Guides etc. Even though I received great feedback from the team, I felt like I had little to show for my efforts. The imposter syndrome was truly kicking in. But then, when I was talking this through with one of the Red Tangerine Agile coaches, I came to realise that my success as an acting Scrum Master wasn’t measured by what I achieved; it was by what the Scrum Team achieved. This was in their achievements in understanding Agile and Scrum better, in the value they had delivered and their journey of continuous improvement.
This whole experience made me think about something I often do when trying to improve the user experience on a product or service. It’s a technique called Genba. Japanese for ‘the actual place’. Go and do. I went and did, and I learnt a lot from it. I broadened my horizons and built on my ability to empathise with the Scrum Master role. Quite frankly, I think this is something that many people need to do.
To all of the great Scrum Masters out there, I will never take the role for granted again. I appreciate all that you do, your dedication to your teams, organisations and Scrum itself, your ability to know when to observe and when to step in and take action, how you create safety for teams to make mistakes and coach them to learn from them, and being that advocate for Scrum while supporting us all
Thank you, Scrum Masters, everywhere!
