I recently saw that I passed my 3-year mark as a certified Scrum master. This seemed a good moment for me to reflect on my experiences so far, and take a closer look at the lessons I learned as a starting Scrum master.

To give a little bit of context, I started as a part-time Scrum master, and part-time developer at the company I currently work at. During the last 3 years a lot has changed, in terms of my own personal development, how the company handles agile and scrum and the teams I was scrum master for.

The following lessons learned as a starting Scrum master are what stuck to me as the most important scrum lessons learned, or the most “aha” moments I had.

Conflicts are not always bad

In the first team, I was a Scrum master in, there were several conflicts. Without the experience I have now, I saw those conflicts as an impediment to immediately solve. If the team is not fighting about code standards, which libraries to pick, or at what time the daily should be, they could be doing actual work. During my two-day training for CSM1, the trainer talked about how conflicts are part of the development process as a team.

My nature is being a peacekeeper, but when I resolved conflicts before they really started, I took away the chance for the team to overcome them, learn from them and become closer as a team. This resulted in the team continuing to work as individuals, and never getting close enough to really get into a mode where they could collaborate, without me as a conflict solver.

Sure, not all conflicts should be played out fully. some conflicts can be more harmful than the lesson they learn. You can compare it to being a parent (or so have I been told). Sure you want your children to learn from their mistakes. Letting young children go outside without their jackets, is something they can learn from. But you will not let them cross a busy road, on their own.

Am I a Scrum master or a developer with extras?

All the professionals around me at the time that were Scrum masters were basically just senior developers with a bit more responsibility, especially with the part-time roles of both Scrum master and developer. This lead me to believe that the role of a Scrum master was the “frontrunner of the team”. You should prepare all tickets technically, make sure the Scrum artifacts and ceremonies are done and will be held responsible if the team is not running.

The first time I started realizing I was just a senior developer with some extras, was during my Scrum master certification. But the truth is, my big “aha” moment came when I read Coaching Agile Teams by Lyssa Adkins. This lead me to re-evaluate how I saw my own position. As the biggest changes, let the development team really be in charge of the development part, so the ownership and feeling of commitment will grow. And focus more on other areas, for example making the whole organization more agile, shifting my style from leading to coaching or giving workshops. Lyssa helped me with the best scrum lessons learned.

Adapt your style to the phase your team is in

At the time I was asked to become a starting Scrum master for a new team to be formed, I was a developer in a team that was in my eyes, really close to being a performing team. Years later I still feel like those were “the good old days” when I look back on being able to deliver value fast.

The team consisted of some very experienced developers who found a mode of working that worked for them. The Scrum master at that moment could do a more loosely role, as the team was responsible enough to make sure we kept running.

At that moment when I switched to a newly started team, I tried to copy what I saw from my Scrum master in the previous team. But that did not work as well. Who could have thought that the more loosely style would work for experienced developers with experience in Agile, and working together for 2 years, but did not work for a group of developers that have not worked together before, and have not worked with Agile?

Tuckman stages of group development describes that there are 4 different stages for teams, and all require a different style of coaching. As a Scrum master in a Forming or Storming team, the style of a more strict Scrum master is will benefit the team more, while a Norming or Performing team can benefit from a more loose role,.

Being a part-time developer does not work

I can be quite honest splitting up your time between a developer and a Scrum master does not work. If you truly feel that improving Agile and the team or even your organization is important, it will take all your time. The pitfall with being a developer on the side is, that I noticed that instead of doing Gemba walks, listening to customers, or experimenting with new approaches I coded.

This results in Scrum masters doing the bare minimum, to make sure they don’t lose any time that they could deliver features. While the true power of the Scrum master lies in getting the organization on board, making the team more empowered, and looking out for continuous improvements. And the trade-off to me was; Do I want to put minimal effort into the growth of the team to make sure I can develop 5 story points per sprint? OR do I want to make sure that because of my full commitment as a Scrum master, the team can do 5 extra points (and even more) without my input as a developer?

If after all of this you still have the feeling that the Scrum master position is not full-time, I advise you to read this post: 42 Tasks for a Scrum masters job

Conclusion

The Scrum master role I saw when starting is quite a lot different from how I fulfill that role now. I would say my perspective has changed for the better, and all of these lessons learned as a Scrum master help me become a little bit better every day. And I even picked up some scrum lessons learned along the way. The most important lessons for me were:

• Don’t try to prevent all conflicts, let the team learn from them.
• Take a good look at your own position. Don’t only follow the examples you have at work, but also look at outside sources and how they fill the position.
• There is no 1 solution that will fit all teams, adapt your style to the phase the team is in.
• Be a Scrum master full time, you will be amazed at what you can do.

If you are interested in more of my blog posts, consider subscribing to the newsletter. Or check the latest series: Engineering leadership.