A customer I was working with asked me to help out with the intake process for recruiting a new Scrum Master and a new Product Owner. I asked them what they had so far. They provided a clear job description describing what they wanted to see from the candidates. They also had a great business storyline describing their goals and ambitions and in what way these impact the people applying for the new roles. They planned two interview sessions and wondered what else could be done to increase chances of finding the right person for the job.

In the past they had created cases for developers. The candidates would prepare these cases at home and present their results, showing their ability to create code. My opinion on this practice is that it makes total sense if you want to test the presentation abilities of candidates, which is not what I want to test because giving presentations is not a main PO or SM skill. We want to know if the Scrum Master is good at doing Scrum Master things, and if the PO is good at doing real PO things. I therefore proposed to create cases like they did for developers, but then for a PO or a SM. We agreed it would be best to prepare real work and let them do that work with the team in a one hour session.

The Scrum Master was asked to facilitate a retrospective with the team. The reason for choosing the Retrospective is because this is the session in which the Scrum Master plays a very important role. The team would then be able to assess the candidates on their ability to listen, facilitate, help the team to formulate action points, personality, etc. Although the Scrum Master is not up to date with all details and does not know the team, he should be able to show his skills by doing a general retrospective using a facilitation format of his choice delivering an improvement action point or deeper understanding of a problem. This will also give him an idea of the team dynamics and will help him to make an informed decision if he would like to work with this team.

The PO was asked to do a refinement session with the team. We chose a refinement because it is such a rich session that requires the PO to take decisions, show his understanding of the domain, work with estimates, deal with stakeholders and team dynamics, etc. To prepare, he was granted access to the acceptance environment to access the product and was given some real wish from the stakeholder, accompanied by a UI design. The stakeholder was present in the refinement session to give more context or answer questions. The work contained unclarities and the information provided was incomplete. As we said, it was real work. We expected the PO should be able to produce a set of sensible estimated user stories within an hour. We were curious to learn what the PO thought of as being most valuable.

The results were great! Experiencing the Scrum Master in action immediately tells you what this person’s soft skills are, how well he can facilitate, if he can manage the time box for delivering actionable items, etc. It is immediately clear for the team if there is a misfit on a personal level too. The Product Owners worked on the same requirements, which was a pretty large chunk of work that had to be split, estimated and ordered. We saw very different results produced by the various candidates. We evaluated the candidates and the results they produced straight after each session. The outcomes were easy to compare because the candidates all worked with the same input material. The candidates that participated all were enthusiastic about this approach.

Downside of this practice is doing the same sessions multiple times for the sake of evaluating a candidate can be a bit tedious. So apply this practice only with the last two or three candidates.

I highly recommend to put job candidates for PO and SM roles in action doing the real work as an addition to job regular interviews. It is a great way (maybe the only way) to learn if a candidate matches your expectations.

This article is directed to all who think that being a Scrum Master is inferior, and therefore think (ab)using the term “Agile Coach” is justified.

Note. A serious warning before you read on: If you consider yourself to be an Agile Coach and you are not up to digesting some painful transparency about your role, please stop here.

OK, so when you read this line, I have captured your attention, which means the agile community might be one small step closer to transparency. Thank you for giving me this opportunity. I want to reward you with the management summary: “We should re-establish the title of Scrum Master to stop the proliferation of oblique role nomenclature. Our professionalism demands this from us; We need to practice the transparency we preach.

Last week I was running a series of interviews trying to find an experienced Scrum Master for a company I am currently working with. They want to scale, and as per my advice we started looking for an experienced Scrum Master to service their teams. We were looking for high calibre candidates. The Scrum Master I am looking for has to be experienced: A person who understands what’s not in the Scrum guide, has empathy, understands the trade off of “not now”, who supports the PO, can deal with 3 to 4 teams, a master in the art of “doing nothing”, a sheepdog that knows how to be loved and trusted and a little bit feared. In other words, I am looking for a REAL Scrum Master. My high standards do not seem to be a problem: Looking at the pile of resumes we got, I was baffled: mainly Agile Coaches applied for the job. 

Looking back at these candidates and the interviews, I observe that people think the Scrum Master title is too common, too ordinary, too inferior and most of all: too cheap. The title “Scrum Master” does not impress friends at parties. Neither does it resonate inside the Agile community, you’re “just” a Scrum Master, it’s a beginners position. Whereas the term “coach” impresses everybody and radiates seniority. 

Friends Agilists, we need to stop this. We need to practice what we preach. We have the obligation uphold transparency in the Agile community, we should not only leave it up to agile institutions to verify true knowledge and experience by certification (like scrum.org, scrum alliance, agile consortium, etc); We need to do more because we are agile.

Firstly, I want to call out to all people that HIRE: Hire a Scrum Master

You stop further deterioration of the title “Scrum Master” by recruiting a Scrum Master when you need one (i.e. don’t ask for a carpenter if you need a macon). You will waste valuable time interviewing them and waste even more employing them. Probably you were tempted to hire an Agile Coach because you experienced the people reacting are mostly Scrum Masters saying they are Agile Coaches, just upping their profile to be invited for the interview. The real Scrum Masters might not apply because your job request is not transparent. Or maybe the reason you are calling out for an Agile Coach is because Scrum says you need one Scrum Master per team and you think that is a waste. It’s easy to do the math: you will pay a bit more for only one Agile Coach, doing the work of two or three Scrum Masters. Here is some news: One Scrum Master can handle multiple teams. So next time hiring, you could try recruiting a Scrum Master and even better, include in your text that candidates using the term “Agile Coach” in their resume will not be invited.

Secondly I need to reach out to all who want to GET HIRED: Be proud of being a Scrum Master.

The title “Agile Coach” is not described in any Agile framework. If you are a rookie and you spiced up your cv to impress HR personnel or head hunters, I hope you will be (respectfully) roasted. The world of Agile Coaches is about money and status. Don’t feed the system with the idea that a Scrum Master is a job of no importance and Agile Coaches are a step up in the hierarchy. This attitude is unethical towards the agile values.

Instead, be open and say you are proud of being a Scrum Master. Show respect to the servant leader management role it actually is. Be courageous towards HR people and explain and teach the aspects of Scrum Mastership. Stay committed to offering opportunities for learning to the teams you dearly care about and to the organisation that employs you. If you are unsure about the complexity of the Scrum Master role, read the white paper by Barry Overveem: http://www.barryovereem.com/the-8-stances-of-a-scrum-master/

Finally, I need to reach out to the Agile community to eradicate this “Agile Coach” virus: Let’s institutionalise this title with proper certification ASAP. Find out more here: http://whatisagilecoaching.org/ and http://agilecoachinginstitute.com/

Am I free of blame? No. off course not. At times I found it troublesome to be a Scrum Master too. I didn’t understand the value of the role either. But after reading this blog, I agreed with myself to reword my linkedin profile title:  Roland Flemm. Scrum Master, LeSS Practitioner and Lecturer.

Back in the early days of Scrum, the Scrum Master role was exciting. The days of the pigs & chickens, the days when being a Scrum Master was considered dangerous.

In those times there was the saying

a dead Scrum Master is a useless Scrum Master 

And even today I still use that when selecting a Scrum Master to work with. 

If you never got fired as a Scrum Master then you probably did not show enough courage to achieve breakthrough improvements.

Scrum Master as a Sheep Dog

As a Scrum Master you would work with the Product Owner on value; coach management on organizational design; and work with the Development Team on self-organization and technical excellence. The Scrum Master would strive for the team to put the product into the hands of the customer every Sprint. It was natural to work on test automation, code quality and deployment. If the Scrum Master would catch a project manager sneaking in from the back, breaking the rules and disturbing the teams, the Scrum Master would go for a frontal confrontation, or as Brian Marick once said:

“the Scrum Master would rip out their throats”. 

The Scrum Master would ensure everyone remained moving in the right direction by challenging, facilitating, teaching, intervening and cajoling. 

Scrum Master as a Lap Dog

How times have changed.

The Scrum Master role I see these days is more that of a lapdog; just like the lapdogs that Paris Hilton carries around in her fancy bags

—sit down, roll over, good boy, have a biscuit—

The Scrum Masters I too often see, are nothing like a Sheep Dog. There are the part-time Scrum Masters: for example testers or programmers who next to their full-time job, also move some stickies around in JIRA during the Daily Scrum, and run a retrospective once in a while.  I see Scrum Masters that represent the teams at the Sprint Review; are the spokesperson of the team to management; Scrum Masters that drive Sprint Planning using JIRA (Agile is spelled differently these days, it is spelled J.I.R.A.) and Scrum Masters that order the Sprint Backlog. 

On top of that, there are Agile Coaches, Agile Coaches are everywhere. Where do all these Agile Coaches come from? and why do you need one? After all, an Agile coach basically does all the same things a good Scrum Master should do. Maybe an Agile coach is just a Scrum Master with presumed better overall skills and therefore wants a better daily rate. 

All this is removing the true spirit of the Scrum Master; the Scrum Master role is going from Sheep Dog to Lap Dog.

The feedback loop on Scrum itself

The Scrum Master is a change agent, a team builder, a servant leader, an innovator and inspires for greatness. So, please do not forget the true spirit of the Scrum Master. You as the Scrum Master, you are the feedback loop on Scrum itself.