Should a Scrum Master be Part Time or Full Time? – Revisited

Six months ago I wrote a post entitled Should a Scrum Master be Part Time or Full Time?. In that post I came to the following conclusion:

“Ideally I think that the Scrum Master should spend most of their time being a Scrum Master. However, my own experience shows me that I am a more efficient Scrum Master if I do the same work as the team so that I share the same experiences as them. This doesn’t need to be a large amount of development work and may even take the form of the Scrum Master pairing with team members. Unfortunately I cannot dedicate as much time as I would like to being a Scrum Master where I work now. Hopefully I will have the opportunity in the future.”

It is my belief that Scrum Masters can only improve if they constantly challenge their beliefs. If a Scrum Master thinks they have the perfect set up and there is no room for improvement then they are dead in the water. Continuous improvement does not just apply to the team or its processes it applies to the Scrum Master too. Six months is a long time and my opinion on the full/part time debate has shifted in that time.

As I stated in the previous post there are two reasons that Scrum Masters are part-time in my organisation. The first was that  resource constraints meant that  having dedicated Scum Masters was not practical. Therefore Scrum Masters were also expected to do development work. Secondly nobody within the organisation (including the Scrum Master themselves) considered that a Scrum Master’s responsibilities were substantial enough to merit a full time job.

At the time I felt that the first reason was set in stone but disagreed with the second. I believed that there were more than enough tasks to occupy a full time Scrum Master if they were to take their team to their full potential. Besides simply running all the Scrum ceremonies and producing the required artifacts there were many useful tasks I could engage in. For example, really going to town identifying and mitigating impediments, pro-actively shielding the team, grooming the backlog, etc.

Subsequent to writing the post I started to question whether or not my organisation really cared if I was part time or full time. After all, surely what they really cared about was that the team was productive. If the team was more productive overall with me as a full time Scrum Master than as a part time developer then who was to argue?

So I bit the bullet and started spending more of my time being a Scrum Master and less as a developer. As expected I never ran out of useful things to do which aided the team’s productivity and started to see a improvement in our velocity despite my contributing less to stories directly. I ran this as an experiment and did not ask for permission. Unsurprisingly management cared more about results than how the team worked internally. There was an interesting side-effect too – my job became less conflicted.

To explain this I will dip a little into the balance of a Scrum team. There are three components to a Scrum team: the Product Owner, the team and the Scrum Master. The Product Owner and team usually have two underlying but conflicting concerns. As the customer the Product Owner is interested in getting as much value as possible and this materializes as getting as many stories completed as possible. The team, on the other hand, is driven by quality. They want to get stuff done sure, but they want it done right. However, quality takes time to bake in. The Scrum Master is supposed to be in the middle balancing the two concerns producing the best possible compromise.

So what happens when the Scrum Master is also a team member? They are conflicted between being a team member and being the balance between the team and the Product Owner. The more I removed myself from development the less of this conflict I felt and the more free I found myself to impose balance without being biased towards the team. I believe that this led me to perform better as a Scrum Master.

Another thing that got easier that was sprint planning. As I have removed myself from development I have also stopped taking part in estimation. Previously I had to constantly context switch between playing planning poker and running the game. This was frankly exhausting and broke up the flow of the session for everyone. This is no longer an issue and the estimates have not suffered for having one less participant.

So far so good. However, in my earlier post I also stated that having a deep understanding of the team’s activities through carrying out ongoing development work made me a better Scrum Master. I still think having a development background can help a Scrum Master deal effectively with a team but I no longer believe that it is not the be all and end all. I have definitely let go of the idea that I have to be hands on getting the stories done. It is simply not as important as being the effective, unbiased glue that holds the team and Product Owner together. Nor does it trump concentrating on actually running the Scrum ceremonies as opposed to also trying to be a team member in them.

Unfortunately I have not fully extracted myself from my development role but I am working on it and am happier and more effective for it. More importantly the team is more productive as a result.

Explore posts in the same categories: Agile, Scrum

Tags: ,

You can comment below, or link to this permanent URL from your own site.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: