I recently saw that I passed my 4 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, part time developer at the company I currently work at. During the last 4 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 Scrum master are what stuck to me as the most important lessons, or the most "aha" moments I had.

Conflicts are not always bad

In the first team I was a Scrum master in, there where 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. On my two day training for CSM1, the trainer talked about how conflicts are part of the development process as a team.

In my nature is being a peace keeper, but when I resolved conflicts before they really started, I took away the chance of 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 got close enough to really get into a mode where they could collaborate, without me as an 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 jacket, 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 where Scrum master where 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 artefacts and ceremonies are done and will be held responsible if the team is not running.

The first times 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 organisation more agile, shifting my style from leading to coaching or giving workshops.

Adapt your style to the phase your team is in

At the time I was asked to become a 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 where "the good old days" when I look back on being able to deliver value fast.

The team consisted of some very experienced developers, and found a mode of working which 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 new 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 either.

Tuckman stages of group development describes that there are 4 different stages for teams, that 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 organisation 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 into 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 look 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 advice 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 fulfil 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. The most important lessons for me where:

• 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 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, check out the challenge I set for myself in the Retrospective challenge 2020