How to Prepare for a Scrum Master Interview, Part 2 – Agile Experience

Photo by Ted Sali

In part 1, I wrote about how to explain the Scrum framework and demonstrate your knowledge. As a friend of mine mentioned after reading part 1, “Describing improvements that happened on your ‘watch’ as a SM is very helpful in interviews. Just reiterating what the Scrum Guide says doesn't really help the interviewer understand how you can drive improvement.” My hope is that the preparation from part 1 will help you stand out as a candidate and—more importantly—allow you and the interviewer to spend more time delving into your experience.

This post is about highlighting your real-world Agile experience and how you’ve helped teams improve. Storytelling is a key skill here.

Managers are generally looking to hire Scrum Masters for one of two reasons: (1) they have a new team that they’d like to get started with Scrum or (2) they have an existing Scrum team that could use help improving their agility. They want to hear how your previous work experience may relate to their current needs. Have a few examples of how you’ve worked in these scenarios to help teams collaborate more, deliver better results, and build trust in their organizations and with customers. Scrum Masters are often described as servant leaders, and we give a lot of credit to our teams for their hard work in delivering products and embracing change. In an interview, you’ll want to be clear about your role in coaching a team to improve. Below are some thoughts on how to do that based on my early agile experiences.

You applied practices from Scrum or other agile frameworks

Many, many years ago I tried introducing Scrum in a digital agency environment. My approach had been to explain Scrum to the group and have a conversation about how it might work for us. Given the number of client projects we were juggling at any one time and changes that could pop up any moment, we ultimately agreed that it wasn’t a good fit for our needs. However, five people did adopt daily standups as a practice, and I applied lean thinking as I tried to limit the amount of work in progress across our developers, focused on work completion and reducing handoffs, and had conversations to identify root causes of issues and determine how to prevent similar issues in the future. I also helped make our release process visible to enable daily deployments to production—with only one QA tester and a lack of automated tests. Getting that process to be stable and run like clockwork was a testament to what transparency can accomplish. And I would wish that process on precisely no one—automate processes and tests more than we did!

With my experience from the above organization, I could speak to giving a group the opportunity to opt-in (or not) to adopting Scrum. An interviewer and I could talk about how Scrum might not always be the best fit and how to introduce agile/lean thinking and specific practices to improve delivery. The keys here are speaking to what I did (managing work for flow, facilitating conversations, introducing new practices for consideration) that led to better results (significantly increased deployment frequency while reducing defects, improved teamwork and their process ownership).

You worked with a new team that adopted Scrum

In another organization, a new team had been formed and gone through initial agile training just before I was brought in as Scrum Master. In the first sprint, the development team had little interaction with their Product Owner who was remote. But they were able to successfully deliver a working product and had a great sprint review with lively conversation amongst key stakeholders about deploying the product and changing business processes to support its immediate usage and resolve current issues. I’d also observed that the team members had some difficulties working together; I invited a colleague to facilitate a DISC workshop for the team to raise our awareness of our behavior styles so we could talk about how we would handle conflict as a team. Their working agreements were strengthened by that workshop. The team’s manager felt pressure to make sure the team delivered and didn’t know what to do to help, and we had one-on-one conversations about it. And when the team struggled to deliver in its second sprint, stakeholders panicked and wanted to know what happened—that sprint review was rougher than the first, as you can imagine. I facilitated a retrospective for the team to identify improvements within their control and requests for management to help them.

Based on this experience, I could speak to the daily observations and conversations I’d have as a Scrum Master to support a team in their early stages of using Scrum. An interviewer and I could talk about Tuckman’s model of group development and how the DISC workshop and creating working agreements made Storming easier later. We could delve into the value of sprint reviews or retrospectives and how I’ve facilitated them to encourage open communication and improvements. I could share what I’ve done to help managers and stakeholders understand their roles. This experience also gave me answers around what I would do differently, like be more explicit with managers and stakeholders about what to expect in terms of delivery from a team as they ramped up and ideally be included in the team’s training and project kickoff events. In this case, my role was primarily focused on the development team and secondarily on stakeholders; I would teach and mentor individuals in-the-moment and coach the team as a whole in our Scrum events and workshops. The result was clear visibility into the team’s work and ability to see progress from a business perspective. A newly hired group of people became a cohesive team that delivered, and management learned how to help them.

You coached an existing Scrum team to improve

Between the two experiences I described above, I had the opportunity to become Scrum Master for an existing Scrum team. The development team struggled in completing sprint work, and they felt like priorities changed all the time. Their product backlog contained about 300 items, including many old defects. The team’s Scrum events were routine and relatively short. After shadowing their previous Scrum Master and learning how they worked as a team, I facilitated different retrospective activities to spark new thinking. I added an additional information radiator next to their physical board that got them reflecting on how long it took stories to be completed during the sprint. A bout of production issues disrupted sprints for a period of time, and the team was able to adapt to surprises because they had learned to limit their work in progress. The retrospectives enabled them to improve quality to stabilize the product. To address priority challenges, I wrote out their backlog—all 300 items—onto index cards and posted them in a conference room we used for refinement sessions and sprint planning. Doing that enabled our Product Owner and stakeholders to see duplicates and obsolete requests in the backlog that could be removed; the development team saw defects that could easily be resolved. It became easier to have a single ordered list for the team to work from—it was magical. Team morale improved, and trust grew with the business as work was regularly being delivered each sprint.

Here my role was being a coach to the team on a day-to-day basis and acting as a bridge with our business. In an interview, I could talk about working with a Product Owner who had limited availability or how to handle interruptions during a sprint. We were inadvertently dabbling with Scrumban as a result of applying lean thinking to our Scrum practices. I learned from that team the importance of unit tests and the differences between refactoring and rewriting. My own personal development included teaching lunch and learns and deliberately practicing different facilitation techniques in retrospectives, as well as mentoring a new Scrum Master and eventually working with a second Scrum team. I could share how we used story points to check for agreement amongst team members and velocity for predicting when future backlog items would be completed and not setting “stretch goals” for the sprint—these were the beginnings of getting more predictability. Business stakeholders and team members alike became happier with our delivery and quality improvements.

Results and Your Legacy of People

Highlighting your experience in an interview means showcasing what you did, the results you incited, and who you positively impacted. Keep in mind that speaking to results means going deeper than “we followed Scrum.” Results are about the problems that were solved or outcomes created by applying Agile practices. As an interviewer, I also love hearing about the people you impacted. The team members, managers, and stakeholders that you coached to be more fulfilled in their jobs or to become more skilled or who gained enough confidence to step into new roles.