Reflections: 175 days as a consultant-turned-scrum master (1/2)
Context
I have taken on various roles and responsibilities working as a management consultant for the past three years. Regardless of the project or role, the core skills required are the same: proposing and refining hypotheses, analyzing data and distilling insights (usually called “synthesis” or “the so-what”), and presenting the recommendation in a narrative tailored to the audience.
Therefore, there is always a huge emphasis on taking ownership of your work, driving it forward, and coming in with an informed perspective, even if what you have in mind might not be the best answer right away. When I was working with the client as a scrum master last year, however, I began questioning whether “taking ownership” still applies in this context — do I really own anything? What does success mean here if I don’t own anything? To what extent should I push for what I consider the right thing to do (and do I really know what’s the right thing to do)?
It took me more than three months to understand that success for a scrum master means that my team is doing things in the best way possible (or at least doing better): they are creating impact, shipping great products, and enjoying working as a team. I decided to share my reflections on what worked for my transition — hopefully they can provide some insights for you :)
What’s in it for me?
If you face a similar transition like me, or just from anything to a scrum master role, the key learnings below can help you adjust to the role. I personally had no technical background (my team ships mobile apps) nor solid understanding of Agile when I started.
If you are transitioning from a do-er type of role to management / leadership type of position, the reflection below might spark some thoughts for you. One of my biggest mentors mentioned to me once that: “good managers might not be good scrum masters, but good scrum masters can be great managers”. I will briefly touch upon where I think the learnings apply to general management as well.
Disclaimer: this is NOT “how you should run Agile as a scrum master”. I am still a novice when it comes to Agile. What I tested with my team worked pretty well, but is that “proper”, “standard” Agile or Scrum? I am sure that there are a lot of debates out there on what “proper Agile” means, so I am not going to distract the focus here.
In addition, I was technically not a fully-employed scrum master given that I didn’t work for the product company (I was still a consultant, if you look at the paycheck haha). I don’t think such situation changes the learnings per se; the only caveat is that the team dynamics was a bit different from a typical scrum team, in the sense that my PO was my client, and that I had additional stakeholders from the consulting side.
So what did I learn from my 175 days as a scrum master?
Learning #1: Building trust is the key
Many have emphasized that trust is critical to most workplaces, and it is especially true for a scrum team. As a scrum master, you need to influence your team without direct authority, and you would also want to ensure that each team player trusts each other (even when there are conflicts of interest) and naturally wants to do the best and help each other out.
So, how to build trust?
- Reduce self-interest
When I was working with clients as a typical management consultant, I cared a lot about owning my work and getting credit for achievements. Such mindset is a taboo for a scrum master. Of course, I do feel proud when the team successfully accomplishes the sprint goal or achieves the changes raised in prior retrospectives, but I rarely attribute those to myself— it is the team’s success! I shifted my mindset from “what can I benefit if XYZ?” to “what can my team benefit if XYZ, and what can I do to help?”
A follow-up question that might surface is: how do I show my value / how will I be evaluated? My approach is to regularly communicate with my stakeholders the responsibilities and impact expected from a scrum master. Depending on the organizational structure, a scrum master can be evaluated in different ways (e.g., by improvement in Agility metrics), but it is helpful to align the evaluation with your role, i.e., helping the team get better (and more agile)!
2. Ask Ask Ask (I promise it is not a Murakami’s Dance Dance Dance parody)
As mentioned earlier, I had no idea what an API call means when I first joined the team 🤷♀️. My lovely engineers were kind enough to explain the terms and got me up-to-speed. You might ask — how does asking questions relate to building trust? Wouldn’t showing how ignorant I am destroy my credibility?
Quick thought: you should show in your questions that you are actively doing your homework. I often asked developers what key terms I should get a hang of and then did my own online research. When I came back with more probing questions (usually on the “why”), it became a more engaging conversation and clearly showed that I was eager to understand how things work in order to be helpful.
For example, when the PO and Design gave feedback on the product quality, I took time to read through materials on testing (including black-box testing, gray-box testing, unit testing, integration testing, CI/CD, etc.), and then asked the dev team where to start. It turned out that even the developers themselves had different opinions on testing (ha!), but we as a team had multiple meaningful discussions on where we were in terms of best practices, where things broke most often, and thus where we should devote more effort first.
As a scrum master, I raised the question on testing when I saw it blocking the team and strengthened my trust-based relationship as a thought partner who asks probing questions 😊
Btw, why do I mainly talk about developers here and less about designers or others? Because the tech world was just so new to me at the beginning! I was naturally closer to design given that I run design-thinking workshops myself.
3. Encourage feedback and appreciation.
My first feedback talks with individual team members were awkward (yeah, like really), but very helpful in confirming what worked 👍 and reminding me what I should do more. I also talked to the PO frequently for quick feedback on the ceremonies (e.g., are standups short and effective? do we need more scheduled backlog refinement time? ), team performance and health, and anything else on the PO’s mind. I also encouraged individual team members to set up quick feedback session regularly with each other (while many of them already had the habit of doing so).
Retrospective, on the other hand, is a more systematic approach to reflect on how we ran as a team in the past sprint, see where we did well (KEEP) and where we could have done better (START, CHANGE). I will share my tips later in terms of how to facilitate Retrospective when you get closer to the team and can sort of expect what the team will talk about.
Here, I would like to first recommend adding an appreciation exercise to the Retrospective agenda. My mentor taught me to use kudo cards as the last section of a Retrospective to end on a high note: I would leave 10–15min to distribute the cards, have everyone write quietly and pass the finished cards to me to put them on the wall. If time permits, I would invite someone from the team to read the cards out loud. Some of them were hilarious — like “I admire your muscles (……)”, some were cute — “thanks for the coffee run 😘”, and some were talking about specific things happened in the sprint — “thank you for bearing with me and helping me out”. Writing words down on a kudo card makes it easier to express appreciation and further strengthen a collaborative, trusting environment.
4. Have some fun together: team events!
I joked once that I am the person who keeps clicking on “maybe” to Facebook party invitations and never shows up (sorry I got so tired and couldn’t leave my bed at 9pm!). Unfortunately, as a scrum master, I had to become the team-fun-event-planner and somehow earned my reputation as a virtual party planning expert since the quarantine.
The idea behind team events is simple: having fun together outside the work context helps the team get to know each other more deeply and associates positive experience with being in a team. For mature and stable scrum teams, it is a great way to supplement the traditional Retrospective exercises and enhance team bonding.
Three games have worked particularly well with our team: playing Overcooked (this was pre-quarantine life), playing online pictionary, and playing a team trivia (where I collected fun facts from each team member beforehand and had everyone guess which fun fact belonged to whom).
For those transitioning to general management: The dynamics can be quite different if you are the product owner / general managers outside the scrum context, where you are directly responsible for the outcome (e.g., P&L of a product line, certain KPIs you need to hit). Nonetheless, some of the key takeaways above can still apply in such context.
For instance, building trust with your team is still important so that you won’t be overwhelmed by taking too much work yourself, and that your team would feel comfortable coming to you when they encounter challenges vs. being too skeptical to speak up. Occasionally, you might wonder whether you can trust someone without many data points; in such cases, you can try a test-and-learn approach to frequently check in first to figure out how reliable a team member can be before letting the person run a complex, critical piece of the project alone.
Giving and receiving feedback regularly is also a critical part of the success formula, especially when you are new at a managerial role. I have worked with new managers and noticed that new managers tend to get nervous easily with the fact that some things are now out of direct control (i.e., in the consulting world, you no longer do the analyses yourself!). It then becomes key to check in with your team on the working style (e.g., do you feel micro-managed or you would like more feedback?) and express how you would like each team member to communicate with you to help you make the transition.
Last but not least, reducing self-interest and focusing on the strengths and needs of your team. It is sub-optimal to only think about “how can I hit my goals, how can I advance in my career?”; rather, it is best to explore the strengths of each team member, coach the individual to leverage that strength, and provide more opportunities for the person to shine. Selfishly speaking, you will benefit the most when your team is performing at their best, right? 🙌
What’s next?
Due to length, I will talk about the other three key learnings in the 2nd part of this article. They are:
Learning #2: Define success from a different angle
Learning #3: You do have a perspective even when you facilitate
Learning #4: Learning never stops
You can read the 2nd part here 🙆♀️
