The trouble with becoming a Scrum Master

The Trouble With Becoming A Scrum Master

Many years ago, when I was starting out as a Scrum Master, I did all the same stuff that everyone else did.

I read all the same books, I went on a certified Scrum Master course, and began to apply all the things I was told to do.

  • I put up a board that said “To do -> Doing -> Done” and filled it with post it notes.
  • I painstakingly drew a burndown chart on the wall and started asking people “How many points are left on this?”
  • I showed up to boring planning sessions and asked people to use poker planning cards to estimate things.
  • And every week I asked my team to stand in front of their stakeholders and show things that they only got criticisms on.

And guess what? It didn’t work!

But it’s OK, I knew the solution; more tools!

So I scoured the internet, but unfortunately what I found was that there really wasn’t a whole lot more out there.

Most of the books I encountered were too philosophical.

They talked about building trust in teams or the importance to cross functionality.

But there were very few that had any advice on how to actually do it.

There were a few actionable things, but as I looked more into it I realised that everyone was just repeating the same ideas over and over again.

It was like one person would have success with an approach, write it down and that would be regurgitated all over the internet as “the next silver bullet”.

Now I have been an Agile Coach for a lot of years, and have had great success in many different teams, and I realise why a lot of the material wasn’t actionable.

Agile is a philosophy …

And you’re not going to have a lot of success …

… Until you understand the underlying philosophy behind it.

Now herein lies the rub:

The philosophy is one of experimenting and learning. And it’s difficult to learn when you don’t have a lot of things to try out.

If the burndown charts and the poker planning cards fail you, there really isn’t a lot of other inspiration available.

“If the only tool you have is a hammer, every problem looks like a nail”

If the burndown charts and the poker planning cards fail you, there really isn’t a lot of other inspiration available.

This means you need to start developing your own ideas from scratch.

Which in turn slows down the learning cycle.

But I kept at it.

I failed, and learned from that failure.

Eventually, I understood the underlying philosophy that truly helped me succeed.

I also developed a much larger toolkit based on the things I had tried.

Nowadays, I have enough things in my back pocket which help me find a starting point for most things I am trying to address.

Things like visualization techniques and workshop structures which allowed me to move beyond the early tools that hadn’t always worked.

In retrospect, what was lacking was inspiration!

Here’s what I now realise:

No matter how long you have been working in teams, you should be looking for new tools and approaches. And you should use those things as an inspiration to develop the activities you are already doing.

With that in mind, I decided to start sharing the tools I had developed over the years.

I attended Meetups. I introduced it to my friends, and they found inspiration in them.

People even gave me feedback on how they adapted my tools in their environment … which in turn inspired me to create more!

It’s like the more you give, the more you develop yourself.

Pretty great, right?

Eventually, I decided to write them down and share it in a format where they could be consumed by a broader audience.

And this is how I came up with my book, “Actionable Agile Tools”.

The tools in it are short, concise, target a specific issue, and above all are something you can actually DO.

None of these tools are  a silver bullet.

They won’t fix all the problems you have overnight.

And they won’t remove the need to understand the philosophy but hopefully they will provide some inspiration!

Download a Free Chapter

Click the link below to get a free chapter of my book:

If you would like to buy the book, you’ll have an opportunity to do so when you download the free chapter.

 

 

4 Signs of success for Scrum Masters – Guest blog post by Kiryl Baranoshnik

5303943819_e4fa8ab2dd_zAs Scrum Masters, we want to know when we are doing a good job. After all that’s what feedback is all about. However, defining the key indicators of success for Scrum Masters (SM) and Scrum Teams is not an easy task. There is no good source for benchmarking or guidance in this respect. In practice the industry still doesn’t have an agreement on what success means for a Scrum Master. Not only is the SM’s job still in the process of maturing, but it’s also hard to measure the main object it deals with: human behavior. Still, as a Scrum Master one needs some cues that would help understand that he or she moves in the right direction. After all Scrum is about inspecting and adapting.

Based on my experience with various teams I developed a set of signs that I found useful in setting a direction for a team’s growth and evaluating results afterwards. The definition is not strict and leaves some room for interpretation but it helps me understand whether I’m going the right way with a team or not. I’ve broken these signs down in four dimensions:

  • Expertise in Agile practices
  • Ability to continuously improve
  • Ability to ask for help
  • Ability to maintain an open culture

Expertise in Agile practices

15415369891_e5dbfea5c6_mAgile practices are what you usually start with in a new team. The end results of this dimension are the easiest ones to measure and evaluate. While focusing on Agile practices, you mostly act as the teacher and mentor as defined in the ACI competency model. Your goal here is to make sure that the team understands and follows Agile practices and is able to use them effectively.

Among the signs of success in this dimension might be:

  • The team does Scrum ceremonies on their own without the ScrumMaster
  • Backlog Refinement is performed by the team continuously, Product Backlog stays in good shape
  • The team applies engineering practices such as CI, TDD, etc.
  • Product Owner is able to work out a long-term roadmap on their own
  • If any estimation techniques are used, they are applied properly

Continuous improvement

As you start seeing that the team has grown enough expertise in Agile practices, you want to move to the other three dimensions. From this point on you act mostly as the coach and facilitator. In the continuous improvement dimension you want to see your team capable of maintaining their growth without active involvement from your side most of the time.

The signs of such behavior might be:

  • The team is able to conduct Sprint Retrospectives on their own and produce improvement action points
  • The improvements are followed up and completed without the ScrumMaster’s supervision
  • The team keeps their agreements and practices, performance doesn’t deteriorate over time

Ability to ask for help

As you see your team practicing Agile and improving continuously, you may want to start nudging them towards self-organization even more by switching your stance to occasional facilitation and on-demand coaching. Here you want to make sure that the team is able to demand this support as necessary, and is able to ask for your help when they run into an impediment they can’t resolve. The best way to move in this direction is to set the team’s expectations by stating a new coaching agreement, for example: “You guys seem to be taking ownership of the method and practice, which is great. So I’d like to step back a bit more. I’ll be here still, but I’d like you to take the lead in asking for my help when necessary. Is that ok with you?”

You can tell the team is able to ask for help when:

  • You get coaching requests from time to time and when necessary
  • When you visit the team to make observations, they don’t surprise you with hidden issues they haven’t told you about

Maintaining an open culture

An overarching dimension that I believe supports everything else is the culture of openness. Openness is also one of the Scrum’s values so it’s one of your tasks as a Scrum Master to make sure it’s maintained. There are different ways you can train the team to act openly. For instance, you can start showing them how to give constructive feedback or how to communicate effectively.

You can tell that they’ve learned the lesson if you see that:

  • Team members solve conflicts in an open and constructive way, don’t bear a grudge against each other
  • Team members help each other eagerly in everyday activities.

What next?

As you start seeing all or many of the signs of a successful team you can say that as a Scrum Master you’ve completed your job successfully. The obvious question arises: what next? Well, at this point you have a number of options.

Since a Scrum Master is not merely a team facilitator but also an organizational change agent as suggested by the Scrum Guide, you may shift your attention to organizational impediments. From my experience I can say that teams reach their growth cap quite soon and eventually bumps into organizational constraints. Those might be, for instance, organizational structure that produces cross-team dependencies or technical limitations such as lack of CI.

The other option is to detach from your original team gradually and move your attention towards the next team. Craig Larman and Bas Vodde argue in their LeSS framework that a Scrum Master may handle up to three teams. So if you started with just one team, now is the best time to expand your area of responsibility.

Good luck, and do share your experiences! How do you measure success in your role as a Scrum Master?

About Kiryl Baranoshnik

captureKiryl Works and lives in Minsk, Belarus. He is an experienced ScrumMaster and Agile Ambassador with EPAM Systems. Accredited ICAgile trainer with AgileLAB. Co-founder and leader of a local Agile/PM community. Former software developer.

Photo Credit by Yosoynuts @ Flickr
Photo Credit by Kanban Tool @ Flickr

A real life story: In search of Value, how we helped a team go from idea to revenues in 2 weeks

Image (cc) by Ron Mader on Flickr

Image (cc) by Ron Mader on Flickr

We wanted to share one of our success stories of how we helped our client to generate more than 250 000 euros in revenue in 7 months with you. We believe that the starting point of any fruitful venture is collaboration and the true value of a good collaboration is the impact it has on the business. Through our partnership we achieved results with our client and at this point continue to work together to develop and deliver even more in the future.
All that sounds very good but how exactly are good collaborations done in real life, you ask? The answer to that is: with simple, value creating tools and techniques. And now our story really begins.

The starting point of any fruitful venture is collaboration and the true value of a good collaboration is the impact it has on the business

Defining the problem is half the solution

In the beginning we were sitting at our client’s office with one pressing question: how can we evolve our product so that it benefits our customers and improves our business? Our client had a clear answer to that question: we want to add something to the product that will help the customer find what they want and therefore generate higher purchase conversion. Fantastic! So we knew exactly what we wanted (“the number”), and that isn’t often so simple. So we were ahead of many at this point.

We wanted to generate a higher purchase conversion rate which is one of the major economic drivers for this particular client. But how could we achieve it?

But our problem was still far from solved. We wanted to generate a higher purchase conversion rate which is one of the major economic drivers for this particular client. But how could we achieve it? We wondered together. We thought long and hard and in order to find the necessary answers we resorted to using product development techniques that allowed the Product Owners and our client’s teams to focus on Value Generation instead of doing just “one more sprint full of user stories” or “adding yet another feature” that would inevitably bloat the product with too many features.

We used brainstorming techniques to generate an impact map of all the options we knew how we could increase the purchase conversion. We wanted to keep people in the client’s website and in the same buying process step across devices. We hoped that this strategy would increase the conversion per user and develop the concept of a permanent search and purchase loop that would persist across all the users’ devices.

So now we have gotten to the point in our story where we know what we want but we still don’t have a feature that would translate that into reality. And so the story continues.

Transforming a goal into a backlog: The Spouse Feature

Photo (cc) Drew Stephens

Photo (cc) Drew Stephens

Again, we sat down and adopted a simple approach. We thought, discussed and planned and after spending several post-it note blocks, we eventually came with an idea of how we could keep people in the purchase loop. We decided to develop a feature, which would allow a person that had been on the site always stay in the same purchase step as if they had never left (so that they wouldn’t have to search again, which would – in our hypothesis – discourage the purchase).

To amuse ourselves and also to credit all the wonderful life spouses out there, we fondly started calling this “The Spouse Feature”, because we all know how important it is to have one’s spouse’s approval for any (bigger) purchase. In addition to The Spouse Feature our brainstorming also resulted in the development of a feature that enabled people to invite friends to the site by using social media. At this point the Product Owner and the Team were as pleased as punch with themselves! We had done a lot of brainstorming and critical thinking and consequently had managed to come up with two lean and mean features. Quick and to the point!

We had come far already but our work was far from over. On the contrary, we were only really beginning our journey.

Just when you think you are done… Until you test for value, you are not DONE!

We knew that as the next step we needed to establish how we would test the swanky new features we had chosen to develop. We had a lot of faith in those features and we strongly believed that we weren’t hedging bets on something useless, but that they could work. Once the feature idea was finalized we shifted focus to establishing our testing criteria: how will we know if these features actually deliver value?

Together with the Product Owner we established clear acceptance criteria for the success of the feature – not just the quality, but also the metrics that would make the feature worthwhile from an economic point of view. For example, we defined the cost of maintaining the feature over time and defined that the feature should generate at least as much revenue as it cost to maintain, aka “The Kill Criteria.”

We defined the cost of maintaining the feature over time and defined that the feature should generate at least as much revenue as it cost to maintain, aka “The Kill Criteria.”

At this point we had developed the features and were ever so keen to test and go live with the features we had developed. As usual, we wanted to keep things uncomplicated and make testing as easy and quick as possible. Therefore, together with the team we designed the features to fit in one sprint so that we could go from idea to measurement of success in only 2 weeks!

This single-minded focus on testing our ideas was important for 2 reasons:

  1. We were only allowed to deviate from the already existing backlog for a short period of time;
  2. We don’t want to invest into a feature too long before we test that it actually works as intended when the customers start using it.

The d-day drew closer and it was time to take things to the next level. Excited, we moved on from planning to implementing and testing the new features.

The proof is in the pudding: testing the features in real life

http://www.dahlstroms.com

Photo (cc) by Håkan Dahlström

When the big day finally came, we were all confident that our strategy and features were good.
The first sprint after going live was all about collecting information about the value of the features. As often is the case, we experienced a few surprises. In the initial stages of the planning, our client’s team was very excited and confident about the “share on social media” feature. It was clearly the bookie’s favorite, but it turned out to be less efficient than we anticipated. However, we weren’t devastated because much to our surprise the second feature (share by email and purchase later, aka “the spouse feature”) showed some real promise during the first sprint: it generated the first purchase conversion in the first day of operation! Well of course it did, you say, because we all know that spouses are always behind any and every big decision. Trust me, we all know and believe it now.

Much to our surprise the second feature (share by email and purchase later, aka “the spouse feature”) showed some real promise during the first sprint

After careful analysis of the data we gathered during the first 2 weeks of the features being in production, we concluded that “the spouse feature” had real potential and we decided to hold off on the “share on social media” feature and focus on the latter. At this stage we thanked all of the creators of Lean Product Development, we had gone from idea to revenues in less than 3 weeks! We kept “the spouse feature” live after the first sprint and continued to develop it by making minor adjustments to improve it over time.

However, the testing wasn’t over yet. So we rested and regrouped and embarked on the second sprint.

The real work starts when you get the first test results

This time our focus was primarily on measuring the impact of the features. As we all know, testing can sadly consume a lot of time and money and produce very little results. We did not want to, or even had the time to, spend too much time and effort on testing, so we decided to go at it with a compact testing period consisting of two carefully planned and executed sprints. What’s even better is that we managed to complete our “in the market” testing in four weeks. Highly effective? Absolutely. Simple. Yes, thanks to the Lean Product Development ideas and techniques we put in place.

At the end of the testing period we sat down to analyze all the data we had gathered. Again, numerous coffees were consumed and permanent markers ran dry as we feverishly ran through figures. Our hypothesis had been that both features, or at least one, would help increase conversion in the purchase loop for the client. Did they?

Testing is step 1, reviewing the results of the tests is step 2

We were right in our predictions, although we had also experienced some surprises. In our case the bookie’s favorite feature (share on social media) failed to meet the acceptance criteria, but the dark horse of the race (“the spouse feature”) went on to be a real winner generating up to 35 000 euros revenue to our client every month since going live.

What did we learn? That by keeping things simple, applying Lean Product Development techniques and being structured in our approach we had managed to focus on the essentials and thus have a real business impact in conversion and revenue increase (an extra 400K Euros in revenue per year!)

From idea to a real business impact: revenue increase by an extra 400K Eur / year!

Our primary focus had always been on the business value: we had a clear business goal and we measured the features against it. Now some might argue that we took a simple approach. On the contrary! Our process was just quite simply systematic and with clear success criteria at all steps. These success criteria steps also implied that we were constantly limiting our risks, while allowing surprises to deliver (as it happened) a large upside. Here are the key questions we asked in all our decisions:

  • how much time to invest?
  • What to try given that we have a very concrete metric for business success?
  • Can we get results quickly? (aka: are the ideas testable and small enough?)
  • How to measure success for the features we chose?

All of these questions were considered before we made our first move to implementation.

Thank you to the team: you rock!

The logo the team created for themselves

The logo the team created for themselves

Most stories are dedicated to the near and dear ones and our story is no exception. By now we’ve learned the importance of spouses, but we could have not achieved our goals without the collaboration of our fantastic team and client. Our work was tremendously helped by the fact that our client had the courage to think outside the box and focused on a real value items with a direct connection to the business goals of the company. Furthermore, we had a clear action plan and we ran concrete, useful experiments to test the features and collected all the necessary data. A big thank you also belongs to our client’s team. Our client really went out their way to motivate the team and got them involved in the development. And the results speak up for themselves: our client generated more than 250 000 euros in revenue in 7 months. Needless to say that we were all thrilled with the results.

At this point we’ve gone through business goals, planning, features, testing criteria, data, post its and a few permanent markers. So is there anything more left to say, you wonder? We like a good story and all the best stories come with a teaching. And because we are suckers for stories, ours is no exception. So here it comes: never forget, that clear experiments and precision, not many features/changes, is the key to success.

Clear experiments and precision, not many features/changes, is the key to success.

Peer Recruiting: How to Hire a Scrum Master in Agile Times

by Stefan Wolpers

In the near future, all creative, technology-based organizations will need to abandon the command & control structures that served the industrial world of the 20th century so well. Instead, they will reorganize themselves around autonomous teams to deal with the complexity and pace of innovation of the 21st century.

In such an agile world, recruiting will become a team decision, and the role of the human resources department will change into a supportive one. Recruiters will need to become servant leaders or facilitators, guiding the peer recruiting process.

The following guide to peer recruiting is based on my own experience in participating in the recruiting of such team members with Scrum-related roles over the last five years. It is divided into 3 parts. The first part will cover the Scrum Master role.

I. Peer Recruiting and the New Role of HR

In the near future, all creative, technology-based organizations will need to abandon the command & control structures that served the industrial world of the 20th century so well.

Instead, they will become self-organized structures, built around autonomous teams. (Think General Stanley McChrystal: “Team of Teams: New Rules of Engagement for a Complex World”).

Note: A good intro in the idea of the “Team of Teams” from an organizational point of view is Culture First’s podcast: Team of Thrones.

In such an agile world, recruiting will become a team decision, and the role of the human resources department will change into a supportive one. Recruiters will need to become servant leaders or facilitators in this peer recruiting process.

The Role of the HR as Servant Leaders:

Peer recruiting does not imply, that HR will be rendered obsolete. On the contrary, HR will in the future continue being a major contributor to the success of the whole organization. However, HR’s role will change from choosing someone from the candidate pool and present that individual to the team as the new teammate. Instead, HR will support the team picking the “right” candidate and ensure that the legal and administrative side is being taken of.

Typical tasks of the peer recruiting process, that HR will provide to a team therefore comprise of:

  • Creating the remuneration package for the position in question (in compliance with the organization’s principles)
  • Handling contractual and administrative issues (social security, work permits etc.
  • Supporting the team creating a job advertisement (if required)
  • Placing job advertisement and run corresponding campaigns
  • Doing background checks and pre-screenings of applicants
  • Organize interviews and trial days (from travel arrangements, and meet & greet to introducing the organization)
  • Collecting the team’s feedback after interviews or trial days
  • Handling the signing of the contract
  • Finally, kicking-off the onboarding process for the new teammate.

These steps hold a significant opportunity for HR to become a change agent for the organization, contributing to its agile transition by ensuring that new hires will have the required agile mindset.

Why bother with the inclusion of the team at all?

You may wonder why a change of process will be required in the first place?

There are plenty of reasons, my top 3 are:

  1. It’s consequent. On the one side, the team is empowered to make decisions that directly impact the return on (product) investment. On the other, they are being patronized by deciding on new teammates for them?
  2. It also means the team has skin in the game. And they will be motivated to go the extra mile to make the new connection work. Now, it is their responsibility.
  3. Last but not least, not involving the team immediately signals to all candidates, that your organization isn’t agile, but merely “doing Agile”—a weak value proposition in the war for talent with an agile mindset.

The current status: 

Few weeks prior to this article, I have been running a poll “How Does Your Organization Hire a Scrum Master?”, and so far over 250 participants contributedsurvey-results-hiring-scrum-masters

It turns out that less than 20% of organizations, that are supposedly agile, delegate the hiring decision to the team itself.

II. The Seven Steps Peer Recruiting Process of Hiring a Scrum Master

(0) What kind of Scrum Master Are You Looking for?

This is the question you will need to answer in the first place:

What is the purpose of building autonomous teams in your organization? Does the organization want to become (or stay) agile? Or is the organization just “doing agile”?

Given that the original Scrum motto of “inspect and adapt” meanwhile turned into a quasi religiously followed set of principles—as taught in any official Scrum certification training—, this question is less trivial than it sounds.

The majority of applicants for a Scrum master role, I have met so far, were following exactly this dogmatic set of principles. And I am skeptical that those applicants would make a good addition to any agile organization. It is all about mindset, not skills. (Read also: Scrum Master Anti Patterns: Beware of Becoming a Scrum Mom or Scrum Pop).

So, in the “team of teams” universe, you should always hire for mindset. While you can easily teach skills, training someone unsuitable in the right mindset will be futile most of the time. Which is also the reason, that in this agile, and complex world formalized, certified experience rarely matters.

Hence, the following description is targeting organizations that want to become agile.

(1) Create a Job Advertisement:

In an ideal world, there wouldn’t be a necessity to run a job ad. Someone in the product development organization would personally know a suitable individual and introduce her to the team. (And the organization.)

Unfortunately, truly agile people—those that are not merely sticking to the letters of their Scrum certification manual—are in short supply. So there probably will be the need to create a job ad for the website, as well as other channels.

I strongly recommend to kick-off the collaboration between the team and HR at this point. Most ads that HR departments produce for agile jobs are simply awful. Their usual “I don’t know what this is all about, but I have to come up with an ad by 12 pm, so I copied the text from a competitor” approach scares away suitable candidates, because they sense the lack of competence.

Instead, I suggest to sit together with the whole team, share a coffee, and get copy of the ad right, by being authentic, and human, and reflecting the culture of the organization.

(2) Run the Job Advertisement:

That is the HR department’s job. However, the team may have good suggestions outside the typical LinkedIn approach. Why not try Reddit, for example? Or sponsoring some meetups of the local agile community?

(3) Pre-Screening Applicants:

It would be helpful for the team, if HR could pre-screen applicants. This could be the standard background check. Or a first analysis if a candidate is suitable for formal reasons or in compliance with internal programs of the hiring organization, for example, diversity initiatives.

Unsuitable candidates should then be at least flagged, and probably be removed from the pool. (Although the team should be aware of that for transparency reasons.)

4) Discuss Suitable Applicants with the Team:

The team members should then be provided with access to all suitable candidates, preferably in the form of anonymized CVs: No photos, no age, no gender, no ethic group, no religious believes—any information on candidates that might trigger a bias of whatever kind should be excluded.

Also, you will to normalize information on a candidate’s public profile, e.g. blog or Twitter or other accounts. A summary such as “A is actively contributing to the Scrum community by running a meetup as well as creating a newsletter with 800 subscribers“ will suffice for the selection process.

If this approach requires a scissor, glue, and a Xerox machine, so be it. Please keep in mind that these biases are triggered on autopilot, and that there is not willpower known to mankind that could prevent biases from interfering with the selection process.

Then have a joined meeting—HR & all team members—and discuss whom to invite for the in person interviews. (A simple dot-voting will suffice in the end.)

(5) Running the Interviews:

The “Hiring: 38 Scrum Master Interview Questions to Avoid Agile Imposters” PDF provides a large set of questions (and possible answers), spanning five categories.

Those are the starting point for the interviews. The purpose of the interviews is to identify those that will be invited for a trial day with the team.

Instead of one or two team members having a long interview with a candidate each, I recommend to run interviews of 30 minutes each with as many team members as possible. The trick is that you split the questionnaire evenly among all of the interviewers and later aggregate the answers. Thus, you will obtain more constructive feedback from all the interviewers.

Tip: Create interview teams of two teammates each: One is asking questions, while the other is taking notes. After half of the interview has passed, they switch roles. The reason for that is that most people are not good at leading the interview and at the same time take meaningful notes. Two people, however, will have a much better chance to recognize signals on the candidate’s side, for example, particular answers or body language.

Note: It is important that exactly the same procedure applies to all candidates otherwise the results are less comparable.

It is a good practice to run these debriefings to aggregate the answers right after an interview round with a candidate. Target for objectivity and have HR handle this task. They are the professionals.

The most important question to answer, however, is the “Would you like work with the candidate?” question. And that one should be asked the next morning. Sleeping on it will sober the interviewers, and thus provide a path to a better decision.

Tip: Go with your first thought, and walk away from any candidate who will have lost the “yes” overnight. Don’t rationalize your decision, as people can be taught news skills, but they won’t change their personality. The trial day is an expensive exercise, and should not be wasted.

Candidates that are not considered for a trial day should receive an answer, detailing the reasons for the decision. I know that legal departments tend to freak out over this. They usually fear legal action, for example, on grounds of discrimination legislation. However, respect and transparency are vital values of the agile community, and should be honored accordingly in my eyes.

Finally, invite the candidates that the team would be interested in working with for a trial day. Let the team make a suggestion for a date, as they need to align a trial day with their own sprint rhythm.

5) Have a Trial Day:

Given my holistic view on being agile, a trial day for a Scrum Master should not merely focus on basic Scrum mechanics. If you do that, you might risk ending up choosing someone who is comfortable with “doing Agile by the book”. (Whatever book that is…)

Hence, the purpose of the trial day is in my eyes to get an empirical understanding how the future Scrum master can support the whole organization in becoming (more) agile. The three main areas, I focus trial days on, are as follows:

The Team: This is the simple part. Good exercises for hands-on learnings are:

a) Understanding the current status of the team: Have an introductory session with the complete team, a kind of “ask me anything” session for the candidate. A simple questionnaire will do the job, for example: 20 Questions a New Scrum Master Should Ask Her Team to Get up to Speed

b) Running a retrospective: Ask the candidate to run a retrospective with the team in question. 30 minutes to prepare for the exercise should be more than generous. Actually, I would expect a seasoned Scrum Master to have prepared retrospectives at hands. (Retromat offers a wealth of exercises to choose from, see also: How to Curate Retrospectives with Retromat.

By retrospective I don’t understand the basic “good, bad, and 2 actions items” 30 min version. I would expect something a bit more sophisticated along the lines of Esther Darby’s and Diana Larsen’s book: “Agile Retrospectives: Making Good Teams Great“.

c) Creating a dashboard with agile metrics:Visualizations are key to stakeholder communication, and I believe the Scrum master should take care of collecting data, aggregating information, and finally providing the gained knowledge in a way that helps the organization grow.

In this exercise, the candidate would be asked to create an initial version of such a dashboard and start collecting the first data. Typical metrics, that are easily available by questionnaires or polls are:

  • Team happiness,
  • Perceived value delivered to customers during the last sprint,
  • Perceived current level of technical debt,
  • The agile health level in the organization:
  • Last, but not least, Team velocity as well as a burn-down chart are both particularly well suited to better understand the candidate’s mindset of being agile.

Note: Acquiring stakeholder feedback on level of appreciation of the production delivery organization will most likely not be possible on a trial day.

The Product Organization: Good exercises for the product organization are:

a) Understanding the current status of the team from the Product owner’s perspective: Have an interview with the Product owner on the current situation from her perspective. Again, a simple questionnaire will do job, for example: 20 Questions from New Scrum Master to Product Owner.

A good candidate will be prepared for that interview, and provide her ideas how to she can contribute to improve the agile product discovery and delivery process.

b) Participating in a backlog refinement:The candidate should participate in a backlog grooming session, helping the team to improve the product backlog of the product owner—garbage in, garbage out, right?

The candidate should demonstrate best grooming practices during the exercise, addressing for example:

  • How to deal with large product backlogs,
  • Bill Wake’s INVEST principle to create user stories,
  • How to handle acceptance criteria (for example, use Gherkin…)
  • The whole estimation vs. estimates process: estimation poker, knowledge transfer, #noestimates, predictability as an agile key metric.

A good candidate can ask the right question during refinement session without having detailed knowledge about the product backlog itself. Handling the process and its principles are in the focus of this exercise.

c) Stakeholders and the Organization Beyond the Product & Engineering: This part of the trial day assesses the future Scrum master’s communication capabilities. “Selling” the product and engineering organization to stakeholders and the rest of the organization is a not just a valuable, but an essential trait to either further an agile transition or maintain its dynamic.

It will be particularly important in organizations with silos and legacy command & control structures outside of the product and engineering organization. Or in fast growing startups with a lack of organizational structure to begin with, particularly when those are sales- or marketing-driven.

The task for the candidate will be to design a basic communication strategy with stakeholders that is suited to support transparency, interaction, and collaboration. (Read more about this topic here: 10 Proven Stakeholder Communication Tactics during an Agile Transition

A worthwhile trial day usually requires a full working day, as well as the attention of the whole team. Which is a pretty significant investment. So, choose the candidates carefully.

Tip: Invite the candidate—as well as the whole team—for lunch. It will be pretty much impossible for the her to play a role for 60 minutes, when interacting socially with several other people at the same time. Having food together brings out the true colors…

Note: Menlo Innovations takes the trial process even a bit further: “So we bring people in and get them to speed date with our own staff. The question is always: would you like to work with this person? If the answer is yes, then we bring them in to work with us for a day, then a week and then a month. If the answer is still, “Yes, I would like to work with this person,” then they are hired.”

(6) Gather Feedback from the Team the Day after the Trial Day

Collect the feedback from the team members the day after the trial day with a simple questionnaire:

  • “How would you rate the candidate’s competence level on a scale from:
    • 1 [Awesome!] to
    • 6 [Thanks, but no thanks.]”
  • “Did the candidate do anything to impress you positively?” (Free text field.)
  • “Did the candidate do anything to impress you negatively?” (Free text field.)
  • “Would you consider working with the candidate as your new teammate?” Three checkboxes:
    • Yes
    • No
    • Don’t know
  • “Should we make the candidate an offer? Three checkboxes:
    • Yes
    • No
    • Don’t know

If the feedback is not unanimous, it is HR’s task to take over. Either by entering the contract negotiation, or provide the negative feedback from the team, and continue the search.

If the feedback is not unanimous, the team should discuss—under the moderation from HR—whether the differences are surmountable or not. In the latter case, the candidate should not be forced upon the team. The team always has a veto right.

III. Scrum Master Certifications—A Necessity?

What about Scrum master certifications, Scrum Alliance’s CSM, for example?

Let Jilles van Gurp answer this question:

“I congratulate Ken Schwaber on his well oiled business of scrum training large parts of the industry (me included) but I believe that he doesn’t honestly believe a two day training is enough either.”

And Dan North describes today’s situation as follows:

“Modern Scrum is a certification-laden minefield of detailed practises and roles. To legitimately describe oneself as a Scrum Master or Product Owner involves an expensive two day certification class taught by someone who in turn took an eye-wateringly expensive Scrum Trainer class, from one of the competing factions of “Professional” or “Certified” (but ironically not both) schools of Scrum training.”

As both Jilles and Dan mention, the agile-industrial complex feeds its followers well. Nevertheless, it’s fallacy to believe that two or three days of Scrum training will be even remotely successful in teaching the participants about Scrum.

Scrum is a framework to begin with, easy to understand, but hard to master. Scrum needs to be adapted to each organization depending on its culture, size, or the kind and maturity of its products, just to name a few aspects of this process.

So, a training—leading to a CSM or equivalent certificate—can only cover the smallest common (Scrum) denominator of all organizations: Artefacts, meetings and procedures. All issues that make a transition to agile complex and hard to master need to be experienced first hand. You cannot compensate a lack of experience by applying a dogmatic process to the letters of a book. That results in cargo cult Scrum.

Therefore, a Scrum Master certificate is more personal branding or advertising than a sign of expertise. However, I don’t blame smart people for rising to the occasion and satisfying the corporate demand for agile management methodologies by creating a certification standard. (Or enhancing their LinkedIn profiles with the right search-terms, as I did myself.)

Conclusion:

If your organization shall become agile, switching the hiring process to peer recruiting will be a necessity. It won’t make HR obsolete but its role will change to facilitating others choosing the right candidates. HR will thus become a change agent, contributing to the agile transition of the organization.

Trying to stick with the traditional command & control process on the other side would signal everyone with an agile mindset that your organization isn’t agile, but merely “doing Agile”.

And why would a true talent want to join you then?

Please share your own experience in the comments.

About Stefan Wolpers: Agile coach, Product & Scrum guy. Author of Lean User Testing: A Pragmatic Step-by-Step Guide to User Tests. You can contact Stefan at Twitter @StefanW if you have any questions related to the article.

Picture Credits: Stefan Wolpers