My Lessons on the Way to the Next Scrum-Mastership

In the last months I had the privilege to accompany a local startup as Scrum Master. The CEO wanted to make his small company more agile.

But what does “agile” even mean? In a first video call I led him from the old, rigid world, where plans are worked on stoically and deadlines are met, only to end up late, over budget and with a product that does not meet customer needs, to an agile world, where something is created that stakeholders really need and that has value. This of course had big consequences for collaboration and also for the prioritization of work.

But that’s not what I want to talk about today. Rather, I want to capture the lessons I learned from the project. Because there were some insights. The most important (and actually not surprising) lesson: Habits and people in general don’t change overnight. And neither do I.

1. Take more time for a deeper briefing: After the first conversation we started right away. I was in a video meeting with the team and the CEO immediately handed me the command: So, Reiner, tell us something about agile and Scrum. All the alarm bells should have gone off in me, because obviously the team didn’t know anything about me yet and so I had to “sell” my idea and myself first. A particularly thankless start. Because as a good Scrum Master (I know that now) it is mainly about listening and not about blarney.

I should have better cancelled the meeting and first agreed with the CEO what he expects from me, where he is with his team, what he wants to achieve, whether he already has a purpose, a roadmap and even knows what he offers to whom. In hindsight it turned out: nothing of this was available. No way I’d send myself so unprepared into the arena again. Better start with a general question round or a short liberating structure. Just don’t talk too much about yourself.

2. Get closer to the goal with smaller steps: Especially with startups you want to get further quickly, “fight through” and improvise in a harakiri style. Isn’t this absolute flexibility, which is aligned to the boss’s mood, also part of an agile thinking? In my interpretation agile practitioners have a backbone and don’t act as if they were banners in the wind. That only works if it is transparent enough what one is doing why and what one should better leave because it is not purposeful. The whole team has to understand why and for what it exists, which principles it follows and what it produces for whom. So: purpose, a few rules for collaboration and stakeholders, stakeholders, stakeholders.

I have seen too often that teams produce something that has no value for the stakeholders in this form - or would have had more value if the team had initially dealt deeply and empathically with the situation of the stakeholders. And, which is unheard of, if they had talked to the stakeholders early or even involved them. How should one prioritize work if that is not clear? I therefore already arrived at the second meeting with the stakeholder map. So we collected stakeholders and then assigned them to a matrix of influence / stake. The team had difficulties to assign the stakeholders to the most important quadrants. A clarifying conversation didn’t help. In the end, the voice of the CEO counted five times as much.

As a Scrum Master you quickly get into a difficult situation when you observe that the team members don’t have much to say. This is an unpleasant “anti-pattern”. I then reported this observation to the CEO in a one-to-one conversation, but I came across deaf ears. He was always enthusiastic about the agile idea, but he just didn’t want to really live it. And several times he ended conversations in the middle of the conversation when the topic became too sensitive for him.

3. Don’t promise magic tricks: At the beginning it was clear that I would be there as a Scrum Master until the end of the year. What can be achieved in three months? We can identify stakeholders, start a daily Scrum and maybe set up a backlog board in JIRA. But if two of the three employees don’t want to get along with JIRA, then it will be difficult with the agile bootcamp.

4. One hat is enough: I was supposed to make the company more agile and initially thought of Scrum. In the Scrum framework, there is a Scrum team consisting of a Product Owner, a Scrum Master, and developers. How does that work when the team (including me) only consists of four people? I quickly realized that not the CEO, but one of the two employees is a born Product Owner. Fit, fast, and agile in mind. However, the role was already occupied. The CEO was naturally the Product Owner. But he did not take on the tasks of a Scrum Product Owner: value optimization for stakeholders, knowing the market well, and prioritizing the backlog.

At the beginning, I tried to be neutral. I was the personified Switzerland, holding back as a facilitator. But increasingly, I wanted to express my opinion. I signaled this with a cowboy hat on my head. When I wore it, I expressed an opinion, an assessment. I thought I was moving the group forward, but ultimately, I disturbed the structure by probably getting too involved. In the next project, I want to lead more diplomatically and only give an opinion if asked twice in a row. At least now I understand that in the future, I only want to be a Scrum Master and not a combination of Product Owner and Developer.

5. Staying engaged: The most important insight for me is that I thoroughly enjoy working as a Scrum Master and that I can contribute to the team’s success in this role. I always think of the cat Momo, who is there, and everyone confides in, but actually doesn’t say anything.

As a result, I have refined my own purpose and mission statement as a Scrum Master. Another insight: I was hiding too much behind tools, but it’s actually about presence and opening a space where people can think and work openly and mindfully with one another. That’s my goal, but I’m still far from it. I’m curious where I’ll be able to gather new insights in the future.