Who is this article for?

All software development professionals will find interest in this article, but those hoping to adopt agile, and scrum in particular, will find the greatest interest.

Project Manager or Technical Lead

Who should the scrum master be?  There’s at least two schools of thought that find gravity with this question.   One position is to employ the project manager in this role.  Another position is to have your technical leader tackle the position of scrum master.

Justifications for both can be made.  The project manager naturally has the people and process management skills required to successfully unblock nettlesome issues vexing the development team’s path to productivity.   But on a deeply technical project, unless the PM is fairly technical, he/she could end up at a disadvantage to a more traditional technical lead.  Hence, the argument to have your key development lead be the scrum master is born on the wings of a sufficiently technical project. Of course, this later position has the down side of potentially drawing the Peter Principle forward in all its majesty.  You hired Sam for his technical ability and now your taking him out of his strong suite.   Rarely a good move.

What about a CSM?

With the emergence of the Certified Scrum Master ( CSM ) credential software development directors are asked whether it makes more sense to get a professional scrum master to do the job.  This seems logical, and in some cases may present the right option.  But for those with experience and discernment, a certified anything is only a guarantee that the individual has at least passed some training and testing.

CSM’s may come to the role with the theory locked down, but it would be advisable to ensure they’ve ‘done it’ and can ‘prove it’.  A heterogeneous grouping of experiences and project types would be a good background for any CSM.  Awareness of any subject matter is important, but knowledge gained a priori has its limitations in the field of software development, indeed most worldly pursuits.  Experience counts deeply, and those who’ve been salted through the mine fields of time and circumstance can and do turn tricks the books don’t tell.

Rotate the Scrum Master Role Among Developers?

This seems like an interesting idea.  Seems is the optimal word here.  Rotate the role among developers and give them a chance to self organize.  After all, this is one of the scrum principles.

Boldly, we did this in my shop.  I can tell you first hand…it doesn’t work very well.  The results were not disastrous, but mixed and inconsistent.  The scrum master is there to facilitate and unblock key issues and risks.  By nature, most developers are not wired for these skills.  In most cases their preference is to solve deep, but abstract problems and/or utilize their creativity to bring their imagination into the world.  The scrum master’s world is never abstract and the problems rarely have a logical conclusion.

Here’s some examples of what occurred during our rotation experiment:

Developer 1 would take all blockers to the development manager and ask him to unblock them.  Dump and run.

Developer 2 saw the scrum master role as a break from developing software.   He was increasingly sick of writing code.  He’d often take over the other developer’s turns as scrum master and before long became the defacto scrum master….just because everyone else didn’t want to do it.  But he wasn’t good at it.

Developer 3 just wouldn’t do it.  When asked why…he gave the perfectly logical answer: “I wasn’t hired to do that job.  I won’t be good at it.”

Developer 4 was great at staying on top of all the details, and orchestrating/facilitating the scrum process, but his natural timidity meant he found it difficult to press upon others for project needs.

Qualities Not Titles and Credentials

So what are we left with?  If job titles, credentialing, and current software development roles offer no guarantee of a successful scrum master than what does?

Here, I would contend, from experience, that the qualities below are essential for a successful scrum master.  These may differ from more traditional scrum teachings, but I offer them up as opinion and reflection to the agile community.

A Driver – First and foremost the scrum master should be a bulldozer.  The person filling this seat should feel comfortable pushing issues forward and untangling gray, often ambiguous problems unaided by higher-ups.  I do believe this differs from the views of Scott Ambler, Ken Schwaber and other scrum proponents.  When they speak of a ‘coach’ one gets the sense the ideal candidate would be equally comfortable leading a Little League Baseball team.  But organizations with size and high market caps are serious and very adult places requiring thick skin and persistence forged in steel.

Detailed and Organized –  This really goes without saying.  A scrum master that is uncomfortable with the details of the software architecture he/she is helping to birth into the world is headed for trouble.  One doesn’t need to be reading the code, but it would be beneficial to have the skills to speak with developers on their level and translate those into business speak.   Being organized is also a natural quality for a scrum master.  As orchestrator of the scrum process he won’t gain any points from the team if he forgets that today is iteration planning or can’t recall which stories are resolved.

Honest With Himself/Herself – No one likes a liar.  It’s easy to be honest in the face of fair winds and successful deliveries.  But, when the rice pudding hits the fan and the scrum master and team are to blame:  a solid scrum master will set the example, take responsibility for the mess, apologize, and find a corrective course of action.  In a nutshell: lead.

Politically Astute – The nuances of human behavior and relationships inside organizations that scale to 3M and GE proportions are not to be trifled with.  A bulldozer needs to know when and where to stop plowing and let a more suitable piece of machinery take over.  Further,  the scrum master should have a bag of tricks.  He should be comfortable in the art of persuasion, know the hooks and hot buttons that pull and push his key stakeholders, and see the organizational hierarchy as a tool rather than an impediment.

It’s Personal and I’m Fully Invested – In my experience, aloof scrum masters don’t do well.  They should see their role, project, and career as intertwined.  Their reputation should be at stake and success to them should be more than just a good stand up meeting, or a well orchestrated iteration review.  None of that matters should the product miss its goals. They should take this personal, and invest themselves fully in the project.  Again, this is leadership. Projects rarely fail because money, time or ideas are lacking.  Their usual course to being shipwrecked starts with….belief.  People need to believe the project will be successful and the scrum master should be its evangelist.

Humility – Lastly, I agree with most other scrum theorists that the scrum master should be humble.  I think this is called ‘servant leadership’ by them, but I’d chalk it up as just good leadership skills.  A good SM won’t boast or take credit for other’s work, but place credit where it is most surely due.  Let me be clear, I’m saying ‘humble’ not ‘without backbone’.

Summary

The picture that emerges for a good scrum master candidate is a leader; not a secretary or a bureaucrat.  My view on this differs from traditional scrum thinking.  Where they see a helper of the development team, I see the scrum master as an active, engaging and dynamic person with a big stake in the game. He or she could have certain titles or credentials to his or her credit or not.  Like so many other leadership roles the core of  what that person accomplishes will be manifested through who they are….rather than what hard skills they may possess.  When interviewing and reviewing potential candidates I would keep this question in your mind: Will the development team and stakeholders believe in this person?  Your project may rest on the answer.