You are on page 1of 4

A true ScrumMaster possesses the following critical skills:

1. Facilitator of meetings – Helps in daily scrum, sprint planning, sprint demo and retrospective

2. Protector of the team – Shielding the team from outside distractions and interferences, which
comes in form like “trespassers”, “uninvited guests” and “requestors”

3. Negotiator – Leading the conversation by focusing on the Scrum values of openness, respect,
and honesty

4. Coach - Coaching the Agile practice of “Individuals and interactions over processes and tools”.
Can help you work with an individual or a team, to clarify personal goals and actions to achieve them

5. Agile Planner – Solid understanding of Agile Estimating and planning

6. Forecast Analyst – Forecasting the number of deliverables possible in an iteration, based on


reliable information and evidence

7. Removing impediments – Identify, track and help remove impediments

8. Communication Expert – when the team is moving at the speed of agile, communication is the
force holding it all together

9. Servant leader – ScrumMaster must have a “servant first” attitude – He/she should focus on the
needs of others, especially team members before he/she considers their own

10. Enforcing Rules – ScrumMaster is responsible for ensuring the correct use of the scrum process

You should look at five things to know he/she is a good ScrumMaster. As you interview each candidate,
see how well candidates measure up against these criteria. At the end of each interview, I simply mark
each candidate with a 1 to 5 score for each attribute, but any sort of marking scale you want will work.

1. Responsible

ScrumMasters are able and willing to assume responsibility, but also know when to step back and let the
team do so when appropriate. A good ScrumMaster thrives on the responsibility without power.

2. Collaborative

A good ScrumMaster works to ensure a collaborative culture exists within the team. The ScrumMaster
needs to make sure team members feel able to raise issues for open discussion. When disputes arise,
collaborative ScrumMasters encourage teams to think in terms of solutions that benefit all involved
rather than in terms of winners and losers.

3. Committed

A good ScrumMaster needs to be as committed to the success of a project as the team. I want to find
candidates who will be tenacious in resolving impediments and highly committed to the ultimate
success of the project.

4. Influential
ScrumMasters often need to lead without direct authority. Being able to influence others is important.
Some ScrumMasters achieve this through persuasive argumentation skills. Others through charisma and
personality. It doesn’t really matter which method a ScrumMaster uses. But ScrumMasters will need to
influence team members as well as those outside the team, so being influential is a desirable trait.

5. Knowledgeable

By knowledgeable I mean either of the technology or the domain. I put both of these in the “is a plus”
category. I do not need a ScrumMaster to be a former technical person. And I don’t need the
ScrumMaster to have worked in the domain of the project. But, each of these is a plus that could set a
candidate apart from other candidates.

Beyond looking for certain attributes of a ScrumMaster’s personality, I want to assess how a candidate
will perform in various situations. To do that, I like to ask a few situational questions of the candidate.

For example:

The CEO is at a trade show and needs two new unplanned features by tomorrow. Last week when this
happened, you just put in a little overtime and wedged it in. Same thing the time before. If you don’t
come through, it will cost you sales and the CEO will be mad.

What do you do?

By asking questions like this, I put the ScrumMaster in plausible, real-life situations and see how he or
she will respond. I can then gauge whether I agree with the response, whether it’s reasonable,
appropriate, and so on.

I like to combine hypothetical situational questions such as the one above with open-ended questions
about the candidate’s own real experience such as:

1. Tell me about the worst advice you ever gave a team.

2. Tell me about one of the times you helped a team that you’re most proud of.

Questions like these are great because they give you insight into a candidate’s specific background. But I
always include some hypothetical, situational questions because that allows me to more easily compare
candidates.

Think about the question above with the CEO wanting the new, unplanned features for the trade show.
Imagine having heard answers to that from five different candidates for your open ScrumMaster
position. The answer to a question like that is often sufficient for me to know which candidate I want to
hire.

Situational questions and a candidate’s answers to them can be a powerful tool in assessing who will be
a good fit for an open ScrumMaster job.

Second Question:

Problem:
Since I am the ScrumMaster I don’t have access to the customers to gather valuable feedback. Without
actionable feedback, the team simply breaks an un-validated product down into smaller and smaller
pieces delivering each incrementally. While incremental delivery is an improvement over a single large
delivery, the reality is that it’s really just a more efficient way to deliver the wrong product.

When I act as PO, it’s easy to miss out on a coherent vision for the team, resulting in the delivery of low-
value work. This can happen when I, lacking customer access or a true vision for the product, simply
stack the backlog with the items I find most interesting or familiar. This results in the team dusting the
app by making minor enhancements to existing features or cleaning up low-priority bugs, but not
accomplishing any meaningful work. In this case, low-value shouldn’t be confused with low-quality:
While the team may be producing high-quality work, it doesn’t mean it’s making a meaningful impact on
the product.

Solution:

Both ScrumMaster and PO, for the most part, are full-time jobs. When the same person attempts to fill
both roles disaster almost always ensues. In the case where I am filling the PO’s responsibilities, the
simplest solution can be to free me of my ScrumMaster responsibilities, allowing me to focus on the PO
role entirely.

Keeping in mind, however, that the team still needs a ScrumMaster. This is an opportunity to identify a
team member who is up for the challenge, and coach them into their new role. If successful, we will
have a new, dedicated Scrum Master, brought up from within the team, and a new dedicated PO with a
background in the scrum process. That’s a pretty big win.

11th Question

An estimate of the hours needed is always one person’s perspective on how long an activity or a task
takes to complete; that’s how Waterfall was always done. The estimation is always provided by
someone who is a perceived expert in doing the task. The technique does not consider the fact that the
actual person who might be entrusted to do the job might be someone different, and he or she might
have a completely different take on the task. The actual effort, therefore, can be at either extreme,
depending on the expertise of the person completing the task.

On the other hand, the team is central to story-point estimation because the technique promotes team
discussion and evaluation of the work involved. It helps the team better understand the task via
collaboration, leading to an agreement on an estimate among team members with varying skills. The
necessary team discussion also promotes and brings to the fore the cross-functional flavor of an Agile
team.
3 question

What do you mean with "on last day"? What does the team say, why they didn't finish them? Are there
impediments? Are the stories too big and should be decomposed? Are they not able to fulfill the
definition of done without external help? Is there even a definition of done? How long are the sprint
cycles? How many sprints have passed? How large is the team?

This sounds like a team without a sprint plan. During Sprint Planning, how do team members agree to
measure Sprint progress? For example, do they identify and prioritize sized tasks against which a
burndown can be tracked?

You might also like