When implementing the agile way of working, companies are left with a decision on whether to have dedicated scrum master or let the role be handled by one of the existing resources in the team.
I have worked in teams with both dedicated and shared resources for the scrum master role and I have formed a very clear preference. The question should also go beyond just that distinction. Because "shared" resource is not just one final decision. It is naturally followed by which shared resource.
I will try to give my observations on a lot of these constellations as some of them has caused quite a bit of frustration for both myself and others in the teams I have been part of.
Dedicated scrum master
Let's start with the dedicated role. The upside of having dedicated resources is of course that they can be better suited for the role. They can have more experience and be better at controlling the process. They should be able to know what works and what doesn't.
The upside of this should be a better run project, less strain on other resources in the project and as a result hereof more work delivered faster. Right!?
The reasoning is sound but in my experience it is a case of
"In theory - everything works in practice".
In the intersection between theory and practice some of the magic from the theory seems to get lost and replaced by - for lack of better word - "anti-magic".
Running a dedicated scrum master has in all instances where I experienced it, given problems. A bit like setting the cart ahead of the horse.
The scrum master and the agile ways of working is hopefully set in place for the project to run smoother and reach its goal most efficiently while still handling corrections along the way.
In the instances where I have been in projects with dedicated scrum masters it has skewed to process over outcome, which isn't really surprising if you think about it. If you have a resource only dedicated to the task of being scrum master, then this resource has 37-40 hours of work to fill with scrum-related tasks.
Tasks that may be very important seen from project management point of view, but not very important in isolation seen from delivery point of view. Yes - if it works as it is supposed to then hopefully it is a giant enabler for the project and hence delivery. But what I usually see is that it ends up being somewhat the opposite.
The scrum process ends up taking on a life on its own and developers and other resources in the team tries to push back as much as possible have time to do "actual" work, while the scrum master will advocate for following the process.
Project management is of course very important. You need control and overview on what can be delivered and what is being worked on in order to do prioritisation. It just should not end up eating away at the actual delivery it self.
A burndown-chart is rarely a delivery in itself.
One way of using dedicated scrum masters is to have them span multiple teams as that acts as a way of filling up their calendar and keeps them focussed on only the minimum required input to keep the project running smoothly.
Shared scrum master
The shared scrum master role avoids a lot of the pitfalls from the dedicated resource, but still has some things to take into consideration. Not the least a decision on what role to take on the additional responsibility.
Let's start with the positives of having a shared resource. The less time you have for an assignment, the more focused your approach becomes. You end up having to focus only on the things that really changes something. So for the Scrum Master role it ends up being only the things that management requires and then leaves as much of the daily/weekly running to the team.
This in my opinion results in a much more lean way of running scrum. It cuts of the fat and only leaves the things that really make a difference in the project.
There are of course some pitfalls. Given that the resource is shared, then either of the two roles this person has, runs the risk of being de-prioritized. Having and executing two roles can be a challenge and it also sets some boundaries on the use of the Scrum Master which may not be there with a dedicated resource.
Having a dedicated resource means that the Scrum Master can go after and run with a lot of blockers for the team members and they can concentrate only on their un-blocked tasks. A shared resource won't have the same capacity for support and hence requires team members to carry a higher load. Some teams thrive in this, others struggle.
Sharing Role
So let's get back to discussing who should then have the resposibility of Scrum Master, if it is to be a shared role.
The end goal of running the "Scrum Process" hopefully is to deliver more, faster and being able to course-correct along the way. Noone would ever run a process just because everyone else does it, without really having decided what to get out of it or why it was implemented - right!?
In order to deliver what is advertised the process needs to be as slim as possible. The end goal is to deliver - right. We need to be able to communicate progress and estimations on what is doable within a given timeframe. That is to keep management happy and give them the possibility to make informed decisions about the project along the way.
We also need to make room for the people working in the project to actually get things done. They should not be bugged down in meetings and exercises just because the process prescribes them. They should deliver clear value.
The reason for reestablishing those points is that I think that they are important when it comes to deciding on which role to take on the responsibility.
If we go pure management/business side, then we run the risk of having someone micromanage and hold process over outcome.
If we go pure developer/executing role, then we run the risk of not having any control at all and hence no ability to monitor or course correct along the way.
Hence my recommendation would be to have someone that straddles both sides carry the extra load. I have seen good business analysts successfully take on the role. I could imagine experienced Tech Leads could do so as well. And perhaps even business oriented architects, depending on their workload in the project.
In short someone that can see the issues that scrum process tries to solve from both sides and keep the process itself as slim as possible to ensure maximum benefit to all parties in the project.
That is as far as I understand actually the core of the agile ways of working. Not the individual parts of the process but the philosophy of getting maximum outcome with as little overhead as possible, while still maintaining ability to change course along the way.
Top comments (0)