SCRUM Master or DRUM Master
Vivek Kr Dubey
Business Technology Partner | Digital Transformation Leader | Strategic Technology Advisor
Although, Agile is becoming more prevalent for IT projects and may (because not always guaranteed) be producing better results in some , but the key question that most of the team members ask is "Do we have right SCRUM master?"
Now, this is not an attack for the role as much as the person playing that role.
I am sure many of the readers would differ based on their experiences but overall this has been interesting question for quite some time and hence this article.
I am sure you would often have heard some of the following comments
a) "This SCRUM master does not understand any bit of terminologies that team uses"
b) "This SCRUM master is very pushy"
c) "All that this SCRUM master does is to ask status, report it and goes home happily"
d) "This SCRUM master does not have any idea on what a TASK is all about"
e) "This SCRUM master does not even help to break the task, rather asks every person to help define/refine stories, break the task and then let the same member track the task too"
f) "Is this SCRUM master really adding great value to the TEAM or delivery"
Well, there can be many more questions or thoughts of an individual. But the reality is that most of the SCRUM masters seem more like DRUM (please don't read as DUMB) Masters whose whole day revoles around pushing members to find & create tasks and then sometimes ask unfounded questions (because of lack of understanding of requirements/domains/technologies as the case may be).
So moreover they are often seen as "Drumming" either on their backs or someone else's.
The importance of the role is "RESPONSIBILITY" and being MASTER of managing "RESPONSIBLITIES" for all this is the MOST responsible role in any Agile Team.
But often this role just seems to be like "Status Collector".
Every person needs time and grooming to become familiar with project,domain,teams but the same should be applied to "SCRUM Master" as well.
This person should be held responsible if "Team is not able to deliver something properly" and just can not walk away with standard comment as "I reported status to Management" and then they have to take next call.
In turn, management should ask the SCRUM master
"How many impediments were reported properly?"
"What is the extent you pushed yourself to get those impediments resolved?"
"What was your role & level of engagement in sorting out any major escalations?"
"Were you limited to collect the status whole day or you were constructive in forecasting and preventing issues early on?"
"Did you bring all necessary parties together to sit together and resolve issues?"
"Did you communicate with other teams proactively considering your team's delivery is dependent on other teams?"
"Do you prepare & ensure any useful documentation, either by self or with others, which should help any new joiner to get better start on the team"
I anticipate that most of people playing this role can come strongly against it but its better to see the world from other side AND there is a bit of learning and maturity can always be extracted out of "Criticism".
Hopefully, a short article without taking much of your valuable time.
Thanks Again