By Harshal Sanjay Deole
Ever noticed a conductor skillfully directing an orchestra full of skilled musicians? That’s what a scrum master is supposed to do as he directs the self-organizing team of developers in an iterative, “agile” scrum development project.
The scrum master must not only provide technical and business guidance to the scrum team, and resolve any roadblocks or problems that block their progress, but coordinate their work with the product owner who is responsible for the overall project and represents the users of the finished software.
His or her work includes maintaining the product backlog (the list of work still to be done) and the release plans for their output, but constantly reshuffling the order of work to be done as the product owner either disapproves a particular story (or required function) or gives a higher priority. It is the scrum master’s responsibility to discuss the release plans with the product owner, and update the product backlog accordingly.
In addition, the scrum master must ensure the scrum team is following the scrum culture religiously. While this “culture” includes elements such as the need for self-organizing groups and a focus on software over documentation, the issue that arises most often is the team properly understanding what it means for a task to be “done.” A good scrum master is expected to make the scrum team aware of the acceptance criteria and the definition of ‘done’ for all the tasks in product backlog so that the story will be accepted by the product owner during the sprint review.
A perfect scrum master would combine deep technical knowledge, business domain expertise and good management skills. He or she would also have the confidence, authority and credibility to make the tough decisions needed to balance quality with speed of delivery. Having a good network of contacts also helps him or her resolve issues more quickly.
I remember one maintenance project for a critical product release that the users were not happy with after its release into production. The scrum master agreed to the need for stories (required work) to fix problems in areas such as performance tuning and was under pressure to deploy those stories almost immediately. The client had hired new developers for this work, having lost confidence in the previous staff, but the necessary software and tools had not been installed by the time these new resources were supposed to start work. This was clearly going to result in another sprint failure.
The scrum master quickly got the product owner and clients to agree to a new “sprint” that would consist of installing the necessary tools on the users’ systems, and completing some stories that included initial analysis of integration with other systems. While this was an important, and correct, decision for the overall success of the project, it required a lot of work to convince the product owner and client.
Because clearing such impediments can often take a lot of time, I feel one scrum master should not be responsible for teams of more than seven resources. Having multiple scrum masters for larger teams often makes more sense.
Finally, a scrum master must also be humble and encourage the team to follow proper scrum practices by example. As the scrum saying goes, “A good scrum master always says `Look what I helped accomplish’ rather than ‘Look what I have accomplished.’
While the essential combination of skills varies depending on the team, from my experience people skills and influence are the “must haves” and will allow the scrum master to find the other skills he or she needs. Previous experience in the organization is also a big plus, helping the scrum master use their personal contacts to find and get help quickly.