Full-time or Part-time Scrum Mastery
part-time Scrum Master versus dedicated Scrum Master, how do we find the balance between these two extremes?
I was a Scrum Master and Developer for many years before I finally decided to become a full-time Scrum Master. It was a step that skyrocketed my development as a Scrum Master. But at the same time, I also lost a synergy with my teams that years later I still miss.
How to solve this dilemma? Whether to be a Scrum Master while also having another role, working side by side with the team, or to be a dedicated Scrum Master, able to focus completely on the role but distanced from the team?
I think back to a startup where I worked when I made the switch, and realise that experience may hold some answers.
Getting started
I started off as a Scrum Master and Developer of the single team they had. It was easy to win my team over.
As their Scrum Master, I quickly busied myself dismantling the top-down, command & control process they had put together, inspired by Scrum. To be honest, I was just bringing some balance, and management were nice people, with good, if misguided intentions. But to the Developers I became their champion, winning them more control over their work and respect for their contributions.
As one of the Developers, I showed them how to work as a team and how to bring focus. And how remaining faithful to the Scrum framework pays off.
Scrum, if done properly, gives you quick and significant results, so I got a lot of goodwill from the Developers for that too. The effect of this was that they were enthusiastic to try the changes I proposed.
Coding together meant they saw me hold true to any agreements we made, however irritating they might seem. In fact, I would often take the lead with the tougher ones, just to reassure them. Help them to believe in what we were doing.
A good example of this was pair programming. The idea was completely foreign to them and initially, I was met with a lot of resistance, especially from management. I pushed on. And gradually they realised the effect it was having on the quality of our work. They also noticed how much fun we were having, working in pairs.
The Developers saw me as a pig. Apart from the acceptance it earned me, being a pig was precious when it came to learning. I was relatively inexperienced at the time and I made lots of mistakes. But my team never held it against me. They made me feel safe to experiment.
In fact, I think it made them realise how innovative it was what we were doing, and they joined in. Scrum became a team effort instead of just my thing.
Being a Developer also meant that I experienced the effect of anything we tried as intimately as the rest of the team. This made learning sharper, and the feedback loops shorter.
For example, my biggest blunder during this time was my efforts to stabilise our team’s velocity. Management put pressure on me to achieve this, but at the time I was also convinced that it should be possible. In the end, I gave up, grudgingly, and accepted that indeed, predictability is impossible in a complex environment. This lesson did give me the tools and the knowledge that I use to this day to make people understand why this is so.
The lessons you learn from your mistakes are the lessons you will remember for the rest of your life.
Growth
By the time we split the team into two, it was easy to get a Scrum Master for the second team. One of the Developers, who had gradually been taking over some of my tasks, was eager to step up.
Since we were so used to working together, we kept finding time to brainstorm and spar, and although we both had our own teams, it actually felt like a partnership. Our learning got even more effective as now we had two teams to experiment with.
Working together meant we stood stronger against management too. We became a power to be reckoned with, which reinforced our positions within the teams — a beautiful positive feedback loop. It made our work a very motivating experience.
Without realising it, these were also my first steps in coaching, and in analysing a team without actually working with the team.
By the time we created our third team, management was deferring to us for advice and guidance. It wasn’t always easy and we had our fair amount of challenges and problems, but as a company, I felt we were actually close to the ideal of Scrum, living the Agile dream, so to speak.
However, for me, this is also the moment when things started to get challenging. I now had two fellow Scrum Masters to coach, and I was also working more intensely with management and especially the Product Owners.
To be honest, management and sales always felt like such a struggle, like I was only making their lives more difficult. I was always secretly grateful if I could find a reason to avoid them.
And I really enjoyed being a Developer. Working with a team for me always felt so much more rewarding. Results are much clearer, and teams are always so appreciative of improvements.
The result was that I would often forget my responsibility to serve the organisation.
Worse still, I would sometimes forget my team too. I would get caught up in the day-to-day work, and I would fail to notice the signs until a situation crept up on us and we would have to go into disaster management.
Like for example one time where I missed friction with one particular Developer. I put it off too long, and eventually, management decided not to extend his contract, and we lost a valued member of our team. That episode still haunts me.
Sure, people told me it wasn’t my fault, that management acted rashly, that it was everyone’s responsibility. But I feel that the whole point of having a Scrum Master is that you have someone who can keep some distance from the day-to-day work and pay attention to subjects like these.
The Switch
The one thing that really made me realise that at a certain point it might be a good idea to choose one role and focus on that was something that came as quite a surprise.
We were working on a pretty complex project and I coaxed and pushed my team into adopting Domain Driven Development. I had read a lot about it and was convinced this was the solution to all our problems.
Unfortunately, I had to leave the team a couple of months into the project. The team really struggled without me and ended up having to rewrite most of our Domain Driven code.
It was a humbling experience in which I realised how easy it is to abuse your Scrum Master powers to achieve stuff you really want as a Developer.
In the beginning, I was just one of the guys, and that kept me in my place, but as my skills as a Scrum Master developed, I got pretty good at convincing people, of acting more forcefully when necessary. I also had lots of goodwill on my side, and I guess maybe even my self-confidence got a bit out of hand.
It taught me how careful we as Scrum Masters have to be to not actually start to manipulate people.
From there my natural response was to pull back. I gave up my position as a team lead. And gradually the disconnect with my team grew. Stopping as a Developer became a bigger and bigger possibility.
On the bright side, I paid more attention to management and sales and started to understand them better. Our relationship got more positive as I was able to figure out better ways for them to work with Scrum.
Eventually, the final straw was my frustration with learning. Dividing my focus between my two roles meant that I was constantly struggling to decide which book to read, which conference to go to. Realising how much more I would be able to learn if I focused on one role became a constant misery.
So I made the switch.
A question of context
In general, the Agile community discourages the part-time Scrum Master. However, looking back at my experience, this seems rash. The advantages of being a part-time Scrum Master are more abstract and therefore harder to visualise, but having laid them out, I can’t help but think that we lose something important by dismissing them.
Perhaps the real problem is not figuring out whether one is so much better than the other, but the fact that we think we have to make a choice. Perhaps were are asking the wrong question.
“The most serious mistakes are not being made as a result of wrong answers.
The true dangerous thing is asking the wrong question.”
― Peter F. Drucker —
Looking at the advantages and disadvantages again, I’m struck by how well they fit the way I developed as a Scrum Master. The advantages worked very well for me at the beginning, while the disadvantages only really kicked in towards the end.
In the beginning there is so much to learn as a new Scrum Master that the advantages really make a difference. After all, even full-time Scrum Masters usually limit their scope to the team.
The framework may seem simple, but it models a seriously complex system. Think of it: figuring out how the various elements tie into each other, the balance of the roles, flow, the Scrum Values, the effect of the commitments, team dynamics, the 8 stances of the Scrum Master, how to facilitate the events.
Conclusion
I propose that the part-time — full-time Scrum Master conundrum is not about choosing one above the other, but about realising that it is about accepting the value of both and giving them their place.
I think we can achieve this by embracing that age-old tradition of the master and the apprentice.
Being a Scrum Master is really about being a craftsman. I think most of us agree that the way learning is organised now — through 2-day courses and certification — is terribly limited.
The problem is that a craft is not about knowledge, it is about experience. Wisdom.
Once upon a time, if you wanted to learn a craft you became an apprentice and learned for years from a master. And you only became a master through complete commitment to the craft.
To me, it seems a solution that applied to the Scrum Master role, combines the advantages of the part-time and full-time role, creating a very effective learning process.
This way, the team becomes a nursery of budding Scrum Masters. Team members can try out the role. Test the waters so to speak, to find out if it fits their character.
Some may find their way back to their original role, but with priceless knowledge of Scrum. And that is fine. After all, allies within the team are invaluable for Scrum Masters.
This fits with ideas from Management 3.0 and Brave New Work, where people can have multiple, flexible roles, and are encouraged to try different stuff. Skills can be learnt, it is satisfaction and your personal skills that matter.
Those who persevere do that by making a conscious choice. Gradually, as they grow, they will eventually run into the disadvantages of the dual role. That will eventually force the need to make a choice.
This need to make a choice makes the commitment crystal clear.
Personally, I think the commitment must also include coaching new Scrum Masters, as it is not only through teaching that we demonstrate the necessary confidence in our craft, but it is through teaching new Scrum Masters that true mastery emerges.
“If you want to learn something, read about it. If you want to understand something, write about it. If you want to master something, teach it.”
― Yogi Bhajan —
As a bonus, this setup creates a clearer career path for Scrum Masters, thus avoiding the dangerous practice of separating the Scrum Master — Agile Coach roles.
The key to making this all work is, I think, a clear understanding that the Scrum Master role must have priority. This makes sense simply because there is only one person fulfilling that role. And it gives a lot of clarity starting off. Again, it makes the commitment clear.
With these thoughts, I think back at the missing synergy I talked about in the beginning of the article. And knowing that a motivated part-time Scrum Master would take my place, enjoying that very synergy I miss, well, that is good enough for me.