When you look at job postings for Scrum Masters and Agile Coachs, you might think you are dealing with superheroes — so much knowledge and experience are expected, so many tasks they are supposed to take on. And as a Scrum Master, you also have high expectations of yourself and bear great responsibility. You are accountable for the establishment of Scrum in the team and the organization and the effectiveness of the Scrum team. You support the Scrum Team, the Product Owner, and the organization by coaching, training, support with removing impediments and acting as a facilitator. In doing so, you naturally want to do as little wrong as possible. But making mistakes is entirely normal and provides an excellent opportunity to learn and improve.
The prerequisite, however, is that one recognizes mistakes as such in the first place. For this, regular self-reflection is essential, in which one asks oneself: Why did I do that? What purpose did my intervention serve? Was it the appropriate means?
One big problem is usually our own ego. We want that others need us, to feel important, and we think of ourselves a bit as superheroes. But if we take it all on ourselves, we may hinder others in their development and sabotage the team’s self-management.
- Team’s secretary instead of Scrum Master: You take care of room bookings, create pages in Confluence, order new office supplies, write meeting minutes, are responsible for making all appointments, keep a vacation calendar.
You are not the Project Management Office. Make sure everyone can book rooms, order office supplies, and create appointments. If that is not possible, work to get the impediments out of the way. Then, if something needs to be organized (e.g. office supplies), discuss as a team who will take care of it. It is completely ok if you take on some of such tasks, but everyone else should be able to do so and feel responsible.
- Nanny instead of Scrum Master: Do you ever find yourself checking the board to see if the user stories’ status is up to date? And if not, do you remind the team members? Do you jump up two minutes before the Daily Scrum and make sure that everyone arrives and the event starts on time? You know your team. But we are not in kindergarten. The people will get used to being reminded of everything all the time. Also, it is not very respectful — do you trust them so little? Discuss expectations of each other at the beginning of the collaboration and in retrospectives. Then leave the responsibility with the individual. If it doesn’t work out, bring up the issue in the retrospective.
- Expert instead of Scrum Master: As Scrum Master, you are the Scrum expert and help the Scrum Team and the organization establish it. However, this does not mean that you dictate every detail and tell how they have to do it exactly. If the Scrum Team is new to Scrum and you want to build a Scrum Board, you might know what a good board should look like. However, instead of just creating it and giving it to the team, it is better to work it out together. Ask questions, listen, and let the team develop the board that’s right for them with your support. As a Scrum Master, you wear different hats: Trainer, Coach, Facilitator, Consultant, Mediator. Become aware of which role you are in and avoid wearing the consultant hat all day.
- The mouthpiece to the outside world instead of Scrum Master: It is important that developers can concentrate on their work and are not always disturbed. You may have observed how you shield the team from any contact with other organizational units and teams. All communication goes through you. By doing this, you make yourself more important than you are and may even hinder the developers in their work. Observe which interactions exist and which purpose they serve. If necessary, raise the topic in the retrospective. If the team needs support because, for example, people outside the Scrum Team keep approaching them directly with questions and interrupting their work, find a solution together.
Have you already discovered one or the other of the mistakes mentioned above? Or perhaps others that are not listed here? The cause is often fear — fear that something is not running perfectly and that this makes you look bad as a Scrum Master. Because then someone could come and ask: Why did you allow this? You should have taken countermeasures before! Of course, you can do that, but the price of safety is high. The team will never come up with great solutions on their own because they get used to it that you are keeping all challenges away from them.
The way out of failure: attention, self-awareness, and consistent focus on trust are essential. Look at everything that happens with a certain curiosity: what is happening and how will it develop. Then, if necessary, hold off and see what continues to happen. You will be surprised how things develop and how the Scrum Team finds a solution.
Of course, things can go wrong sometimes. But a mistake also gives the Scrum Team the chance to learn and improve.