My 5 biggest screw-ups as a Scrum Master
“Scrum Masters are true leaders”. A small part of the 2020 Scrum Guide. True leaders. What does that even mean, anyway? I saw this nice post by Simon Sinek on LinkedIn the other day:
Two things that I took away from this post:
- Simon Sinek’s posts get a crapton of likes no matter what he posts
- “Leadership is taking care of those in your charge”
I’m not going to say Scrum Masters are in charge of the Scrum Team, because they most definitely are not. But it did trigger me to think deeper about that. What does “taking care” mean? Does that mean we bring them coffee? Give them a nice massage when we can go back to the office? Send them a care package? Showing the way and demonstrating the desired behavior is the most fundamental element in my experience.
Show me the failure
As my previous post stated, being a Scrum Master starts with empathy. Leading, showing leadership, though, to me starts with leading by example. And that’s hard. You want to be the example. I was talking to another Scrum Master the other day and he was sharing how he failed during his Sprint Retrospective. Failed to provide the right context to the Scrum Team, failed to explain the purpose of how he wanted to conduct this specific Retrospective.
A: he didn’t fail, he learned. He learned what did not work. He learned to be more explicit about how he discusses the purpose of Retrospective design. B: This, to me showed the true nature of being a leader. Being so open about his personal sense of failure means being vulnerable. Admitting that you’re wrong. That’s honestly one of the most powerful examples anyone can give. It tells others that it’s okay to “fail”. You’ve tried something and it didn’t work. Inspect and adapt. So here is me, being open about where I learned the hardest lessons.
1. I’m not always right
This was the hardest thing to learn when I was less experienced. I’ve done my courses, I’ve obtained my certifications on the highest levels. Organizations hire me to help them. I’m right, right? Wrong! Telling others what to do, does not work. In my head it did, but in practice not so much. I definitely had the best of intentions to help them. For instance by running Scrum by the book. And I just went in there with a theoretical approach and that just doesn’t resonate really well when I stick to my own opinion. I didn’t consider the cultural factors in the beginning and the learning ability of the people involved.
How did I inspect and adapt? The first thing that happened was that I was confronted by the people that I worked with. It was harsh feedback. And I took it to heart. Wallowed in it for a couple of days. Then I started to place myself in the other person’s shoes and view myself through their eyes. And I tried to figure out what they would need communication-wise. Both for myself in order to fulfill my assignment, but most importantly for the client to meet their goals. That shift helped, although the relationship was damaged beyond proper repair in hindsight. But it was something that I took with me with every single assignment after that.
2. Teaching people about feedback is a lot easier than receiving it at first
The concept of feedback is easier to understand than it is to digest actual feedback. However, teaching people about it was a whole lot easier than receiving feedback like the mentioned above. It can hurt when you don’t keep in mind that people are sharing their feedback in order to help you grow, to improve you and your work.
How did I inspect and adapt? “The proof of the pudding is in the eating”. I went on an active hunt for feedback, until the point of annoyance to others. It was building skin to myself. I remember someone saying something like “the only right answer to feedback is “thank you”. So every time I got feedback, I responded with thank you and then started to think about how I could use their feedback to improve myself. That helped to really accept feedback and use it for the better.
3. Assume people are naturally self-managing in organizations
Self-management and autonomy are not given from one day to the other. However, in the early days of my not-too-long career, I always felt people would figure it out themselves. “From now on you’re self-managing, enjoy!”.
It’s something that I see organizations do in general, and also how this does not support actually achieving a state of self-management. It ended in a lot of things; frustration, confusion, disarray, but not what we wanted to achieve. It never ended in a state of actual self-management.
How did I inspect and adapt? I’ve started to challenge the organizations that I work with from an early stage to think about this question; “what do we define as self-management, what does that mean?”. Stephanie Ockerman and Simon Reindl mention self-management as a stool with 3 legs; boundaries shared goals and clear responsibilities. These provide a good start of the conversation, then to be relatively formalized (open for inspection and adaptation) so there is a good start with everyone on the same page. This sets a direction and vision about what state we want to achieve when it comes to self-management and how we feel we need to get to that state.
4. Miss out on signs of a lack of trust
Damaging and dangerous. Sometimes it’s easy to go along with the day-to-day business of the organization and all the questions you get, that you forget to check in with the foundational need of a team in order for it to work, which is trusting the people that you work with closely.
That’s exactly what I did in one of my assignments. The developers seemed to be getting along quite well, while in fact, they could drink each other’s blood. This was a group of people already working together for several years, but I should have done a proper check.
How did I inspect and adapt? I tried everything I could. A.o. COIN feedback, team agreements, team building events, out for dinner, one-on-one honest feedback, and heart-to-heart talks. Including their manager. Including the trusted person of the organization. But after more than a year of trying, I still wasn’t able to fix it. I know now I could have never fixed this situation anyway, but at least that would have been clear earlier on in the process. More professional help might have been in place (as this involved more of a psychological approach than I could ever offer). Sometimes it’s good to know when to stop.
5. Work beyond my experience
When I just started, I was asked to be an Agile Coach. To guide an organization new to Scrum, and business agility in general, into adopting this new mindset and cultural paradigm shift. Despite bouncing back from a burn-out my answer was “of course I can do that! Easy”.
…. It was not. It was not completely honest to both myself, nor the client. I had a good connection with the teams and I could help them, BUT I think a more experienced person would have been able to help them more.
How did I inspect and adapt? It was a tremendous learning experience. I’ve become brutally honest about everything that I know and that I can do. If an assignment would overwhelm me, past-me would still have said yes. I realized that it’s a two-way street; the assignment should fit me, too. As well as that I should fit the assignment. Honesty prevails (which sometimes really is annoying to admit). You can’t grow if you only stay within your comfort zone. And that’s scary sometimes.
To me, a true leader is someone who dares to show how failure looks like that him/her, and how to work with it. How to bounce back and learn from that experience. I hope this article can inspire you to think about what your biggest learning moments have been and how you retaliated. And feel free to share your lessons, as it may inspire me and others to rethink our behavior and approach. If anything, it’s my mission to inspire and connect people, so we can develop as a community and work from within. Work from intrinsic motivation. I’m curious already!
