Hi friends! This is the 2nd part of my reflection on working as a scrum master for a team of ten at maximum. We were shipping a brand-new product that just launched its MVP 4–5 months before I joined.
For more details on my transition, how this article might help you, and Learning #1: Building trust is the key, please refer to the 1st part of my reflection on Medium:
So what else did I learn from my 175 days as a scrum master?
Learning #2: Define success from a different angle
I had an identity crisis shortly after I started my scrum master role: my fellow designer friends were leading user research, user testing, and designing amazing wireframes; my engineering friends were leading the technical assessment of potential partners and building each feature; my BizOps friends were tracking competitors and exploring market opportunities to inform the roadmap.
Everyone was contributing to the product success in a concrete way, while I just seemed to sit there staring at Jira and shout “standup” every day — period. It made me really insecure that I was not producing any tangible outputs.
To ease my insecurity, I read through the responsibilities of a scrum master for another time.
The scrum master is the team role responsible for ensuring the team lives agile values and principles… the Scrum Master is a servant-leader for the Scrum team…. helps everyone change the interactions to maximize the value created by the Scrum team.
(Source: Scrum.org, Agilealliance.org)
I realized that I was using an old success framework (i.e., how impactful are the outputs that I have produced) to evaluate my performance as a scrum master, which was a wrong approach from the beginning. My updated success framework is as below:
- Product: Are we shipping higher quality product? Are we delivering the vision and high user value?
- Team: Are we doing better in terms of productivity, team health, collaboration between functions and roles, and team’s relationship with the Product Owner and other stakeholders? (Technically, I should also evaluate to what extent we lived Agile values; I didn’t set that as high priority merely because I was still learning what Agile entails and didn’t want to “force” any metrics on the team)
- Growth: Am I developing my skills as a scrum master? Do I understand what Servant Leadership means? Am I leveraging my past experiences to help the team?
For those transitioning to general management: As a manager, you are likely to have a milestone to hit / an OKR to meet that is generated top down. While such goals are the primary success metric for you and your team, it is also important to track and evaluate the less tangible improvements, e.g., is the team taking ownership? How is the team managing stakeholders?
Another major difference between scrum masters and general managers is that scrum masters have no direct authority over the team, whereas general managers typically do and can rate individual performances. Great managers are able to leverage that authority but not over-rely on it; they not only hit their primary success goals but also the second/third-tiered ones.
It’s easy for me to simply describe what I consider the best general managers without doing that myself lol 👩💻. Nonetheless, I have met great managers from my consulting life, who not only successfully delivered what we promised to the client but also supported me to grow professionally during the project…with FUN!!
Learning #3: You do have a perspective even when you facilitate
Recalling that in the opening paragraph of Part 1, I mentioned that taking ownership and coming in with a perspective are key to success in the consulting world. When I first switched to scrum mastering, I basically shied away from having any perspective given that I was not an expert in design, engineering, nor product, and I thought — “You know, I am facilitating the team and shouldn’t have any perspective myself!”
Is that true?
There are two counter-arguments. One, a scrum master is the expert in Agile and therefore should have a perspective on how well the team is working together. Two, without a perspective, it’s hard to facilitate a team conversation — I mean, you can and should always ask open-ended questions (e.g., “so, how do we feel about XYZ? What do we think we can try out next sprint?”), but it’s hard for me to react on the spot without any prep work.
Facilitating Retrospective exercises was a great practice ground for me to balance the art of facilitation on the spot and cleverly guiding the team towards a certain direction. As I spent more time with the team, I had a pretty good sense of what was going on across the board each sprint, so I was able to preemptively design exercises on those key topics. What I prompted the team to talk about were topics such as:
Quality control: Did we test properly this sprint? Were we rushing to ship things out?
Scope: Was sprint planning effective last sprint? Do we need more grooming time to scope out the big features? How do we feel about entering the new phase of the roadmap?
Changes in team configurations and/or working style (e.g., everyone WFH during COVID-19 pandemic): What are things that might need adjustments? How do we feel about our current cadences?
On the other hand, of course, what I expected to be the key discussion was always my expectation, and I had been working on the skillset of just going with the flow during a discussion. I love staying organized and planning everything ahead, which is both my strength and weakness.
For those transitioning to general management: The most relevant example I can think of is the need to facilitate and/or present in meetings and workshops. In such cases coming in with a perspective means, first, that you have a clear idea of what you consider the best actions and recommendations and/or the potential goals you can hit with your team, and second, that you have anticipated possible questions and pushes from the audience based on their agenda.
The second part is not easy and requires communication with different levels (sometimes informal, “back-channeling” type of conversations 🤷♀️). When I was in consulting, I was constantly amazed by how senior leadership was able to around the floor to find senior clients, semi-casually talked about life and how things had gone, and then came back to the team to review the work and point out the next direction.
Learning #4: Learning never stops
Last but not least, always keep learning!
Towards the end of my scrum master adventure, I realized that I had matured quite a lot in terms of guiding and helping the team but still had a ton to learn (and probably more than what I thought I had to when I first started). I have learned that Agile / Scrum is a very contextual methodology, and the interpretation varies by Agile experts. Thank you folks for helping me navigate 😊.
I am also super excited that I got to learn about technical terms, participate in testing, join user interviews, and learn about design systems (thank you team!!). Product is such an interesting world and has so much more for me to explore.
If I were to summarize the most important takeaway here about learning, I would say that it is perfectly fine to not fully understand something. All you need to do is keep asking why things work a certain way and asking for advice on how to get up-to-speed as soon as possible.
