I've seen some companies moving towards the "True Agile" concept of software development and in that process stumbling upon an idea of "no scrum masters".
Now, some people may misread it as "self managing team" and that's where I think the trouble begins.
I worked with a company which decided one day that they would like to set up their own version of the "Spotify Model". (Read here to know more about what it actually is)
The issue started when they thought that the first step in that direction would be to get rid of the "scrum master role".
Of course it had a little bit of resistance but not something managements haven't seen before. But what I am surprised by are the points they (or anyone in the favour) used to justify this:
1. "Scrum master role is something which should be shared by the team and "Agile coaches" are added as "trainers" to train the team."
Firstly the name "coaches" is very misleading.
A "team" has a coach whose responsibility includes to guide and train the team, and also to keep them working together like cogs in the wheel. Whereas, these coaches are more like "doctors" who will be able to help only when a team is able to self-detect a symptom which is causing an issue.
A coach is supposed to be monitoring every aspect of the team's performance continuously and also help in key decisions, which these people are definitely not doing. They are just suggesting approaches which might help in situations based on what they have learnt in their trainings and experiences, and I think if a polio vaccine has cured millions of people it might not mean it is a great vaccine for covid-19!
If we then decide to make them more accessible and included into the teams then anybody would argue about the difference between them and a scrum master.
2. "Teams to manage inter-team dependencies themselves."
This is a full day activity in itself for which traditionally a scrum master would already be collaborating with few people from each teams, which now comes on the shoulder of a "Tech Lead" or a "Lead BA" who might be the only ones who (are supposed to) have end to end knowledge about the software.
Now if these key people are going to do the inter-team dependency resolution and at the same time do their day-to-day work - please don't complain about velocity!
3. "Teams do not need "protection" from stakeholders."
Ideally, yes! They should not be needing it, BUT it's usually not the stakeholders who are the ones they need protection from. It's those people in "management" who without having much idea about the nitty-gritties of the software have committed some deadlines which suddenly become a ticking time-bomb on everyone's head. A good scrum master is supposed to prevent that from happening by being the key person in those discussions and justifying the reason why 5 seconds is too less of a time to deliver a baby!
There was a time when I practiced eXtreme Programming and I really did not make much sense of this role too, honestly speaking. But that was because how the team was structured and the kind of software we were developing.
We were not following "scrum" and did not have a "project manager". All we needed was a Product Owner who knows his/her product well and either can put the requirements well into a story or explain it well to a BA. Following a kanban board to pick cards from and keep our CI/CD on top priority made it so easy!
But since then been working in multiple scrum/kanban projects which have so many dependencies and team/stakeholder handshakes, I have realised the importance of this role (though I have some reservations about scrum in general but that's a different post in itself!)
I see a scrum master as a "stage director" who might always remain behind the scenes but makes it easy for everyone in the crew to understand the exact timing when they need to enter the stage.
If we want a team to function completely without a "scrum master", may be "scrum" itself is not the best solution for us!
Top comments (0)