So You Want To Be A Scrum Master

So You Want To Be A Scrum
Master?
A collection of ideas, thoughts and
learnings from the agile community
at NewVoiceMedia.
Helen Lisowski, Rob Lambert, Martyn

Frank, Raji Bhamidipati, Steven
Mackenzie and Keith OSullivan
This book is for sale at http://leanpub.com/beascrummaster
This version was published on 2016-06-07
This is a Leanpub book. Leanpub empowers authors and

publishers with the Lean Publishing process. Lean
Publishing is the act of publishing an in-progress ebook
using lightweight tools and many iterations to get reader
feedback, pivot until you have the right book and build
traction once you do.
© 2016 Helen Lisowski, Rob Lambert, Martyn Frank, Raji

Bhamidipati, Steven Mackenzie and Keith OSullivan
Tweet This Book!
Please help Helen Lisowski, Rob Lambert, Martyn Frank,
Raji Bhamidipati, Steven Mackenzie and Keith OSullivan by
spreading the word about this book on Twitter!
The suggested hashtag for this book is #nvmagile.
Find out what other people are saying about the book by
clicking on this link to search for this hashtag on Twitter:
https://twitter.com/search?q=#nvmagile
Dedicated to everyone at NewVoiceMedia who are working so
hard to provide the highest level of service for our customers.
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . 1
What to Tell Your Mum When She Asks What You

Do for a Living . . . . . . . . . . . . . . . . . . . 2
Scrum Master is a Strange Job Title (but we don’t

have a better one) . . . . . . . . . . . . . . . . . . 7
How to Tell People What to Do Without Telling

Them What to Do . . . . . . . . . . . . . . . . . . 12
How Do You Become an Expert in a Room Full of

Experts? . . . . . . . . . . . . . . . . . . . . . . . 16
What Has a Scrum Master Ever Done for Us? . . . . 20
You’re Not the Admin Lacky . . . . . . . . . . . . . . 24
Being Effective and Liked . . . . . . . . . . . . . . . 27
New Team Members Adopt the Same Behaviours as

the Team . . . . . . . . . . . . . . . . . . . . . . . 30
This is the Team to Get it Done . . . . . . . . . . . . 33

CONTENTS
Using Small Steps When Big Changes Might Be

Resisted . . . . . . . . . . . . . . . . . . . . . . . 35
Why is Coffee Important? . . . . . . . . . . . . . . . 41
Being Flat Out Busy is Not Effective Agile . . . . . . 44
The Framework Curse . . . . . . . . . . . . . . . . . 48
The Kind of Person Who Knew Too Much . . . . . . 51
No Process is Perfect, but it Doesn’t Mean it’s Crap . 53
Poor Requirements . . . . . . . . . . . . . . . . . . . 56
Reduce Failure Demand . . . . . . . . . . . . . . . . . 59
Inflicting Help . . . . . . . . . . . . . . . . . . . . . . 62
Agile Consultants Who Don’t Know What it Means

to Be Agile . . . . . . . . . . . . . . . . . . . . . . 66
What Would a Customer Say if You Shipped it Now? 72
Whilst Doing This, You’re Not Doing That . . . . . . 74
Scrum Master - What Happens Next? . . . . . . . . . 77
How We Learn . . . . . . . . . . . . . . . . . . . . . . 80
Acknowledgements . . . . . . . . . . . . . . . . . . . 90
Introduction
This book is the result of a Hackathon.
Whilst the devs were busy hacking code the Agile Com-
munity Of Interest here at NewVoiceMedia decided to hack
around on a book.
This book is a collaborative effort by the community to
provide something free, and hopefully valuable, to the wider
agile community.
We wrote this book for new Scrum Masters, or those planning
on tackling the Scrum Master career. Our goal was to ship an
eBook to LeanPub in 48 hours.
We achieved it and you’re reading it now.
We appreciate your support and we really do hope you enjoy
the book. We certainly enjoyed creating it for you.
Thanks,
Rob Lambert (on behalf of the Agile Community Of Interest)
NewVoiceMedia, Basingstoke, England.
15th April 2016
1
What to Tell Your Mum
When She Asks What
You Do for a Living
Thanks mum
We’ve all been there. Your family all get together and after
a couple of drinks someone looks across the top of their 3rd
glass of wine and asks: So what exactly IS it that you do?
What do you say?
This question is even tougher to answer if your family don’t
work in IT - they have no starting point on which you can
2
What to Tell Your Mum When She Asks What You Do for a Living 3
build out their knowledge.
Why is this question even

important?
Sooner or later you will need an answer for a manager or
senior executive who has never come across agile before. Or
perhaps, worse than that, they may have an inaccurate view
of what agile working is all about.
You will have around 2-3 minutes to make your case well.
You will need to be clear and succinct. You will need to take
someone from zero understanding, to a reasonable starting
place. In 2 minutes.
Ladies and Gentlemen, may we

remind you of ‘The Elevator Pitch’
The idea of an elevator pitch is common in the sales and
marketing worlds, and the concept is exactly what we need
here. Can you, in 2-3 minutes, convey the essence of what a
Scrum Master is or does to someone who has never heard of
one before?
One approach is to practice trying to convey this idea clearly
to your mum*. If you can help her, as a lay-person, to
understand, the same pitch will probably work for a CEO.
We need to start from the beginning. What we need is an
everyday analogy. It worth saying that there is no single
correct answer.
It is also worth saying that there are some things we really

want to avoid saying. Let’s start with a couple of those.
For instance, you may have heard people describe being a
Scrum Master is a bit like being a parent. This is frankly rude
and condescending. You are working with super-intelligent
and skilled software engineers, testers and product owners.
They are not equivalent to little children.
You are also best to avoid comparing a Scrum Master to a
project manager. In any way at all. No. Just don’t even start
with that one.
If you start at a place the Executive already recognises, such
as a Project Manager, they will not hear any of the qualifiers
with which you follow it. You have pointed them at a schema,
a mental model, that they recognise, and they will stick with
it. Sadly, your pitch is finished and you missed your chance.
So what could we say instead? Whatever you say needs to be
in your own words, so don’t skip ahead here looking for the bit
you just need to memorise. Instead, here are some ideas you
might like to think about and weave into your own elevator
pitch.
Ideas
Scrum Masters:
Help each member of the team to be the best

version of themselves.
Help each team member contribute their best

version of themselves and their skills, along with
the other team members, to work in harmony.
The Scrum Master here is the oil in these gears

- of no real use alone, but invaluable in keeping
the machine healthy and running smoothly.
Are the agile expert for the team.
Coach the team in process, practices and any-

thing else they can help with.
Spot waste within the current processes.
Shine lights into the darker corners where others

are keen not to look too carefully.
Help people to do the ‘right’ thing rather than

blindly follow a process.
Maximise the time a team member spends doing

what they love, and less thinking about how they
should be doing it.
Help the team to build great habits, both as

individuals and together as a team.
What our ‘mums’ really said

Whilst writing this chapter we had a chat about what our
own families thought we did. Here are some quotes* from the
families of the Scrum Masters who contributed to this book:
Similar to a project manager, but more hippy.
When quietly asked by my dad if she knew what a Scrum

Master actually did, my mum replied “well, you can google
it, but you’ll be none the wiser”.
You talk to people and help them do their best

work. (10 year old)
Listen patiently to the team and delegate as ap-

propriate.
You all just stand around talking to each other

about post its, drinking coffee, wearing check
shirts and converse.
A project Team Lead?
[Doing what?] Put together time lines and give

them to other people to finish on time. [No, but
I sometimes help people predict what might be
finished by a particular date, and ask them to
find the most useful parts to do first] Like a pre
sales engineer, manage people’s expectations?
[Mmm, someone else is managing expectations.
The actual job title is Scrum Master] What’s that?
Some kind of Jedi?
*other family members are available and can be substituted

**There was a common theme amongst our family members
- many refused to even try and understand it, instead finding
all attempts to explain, utterly hilarious. That’s families for
you!
Scrum Master is a
Strange Job Title (but
we don’t have a better
one)
Jack of all trades, master of what?
Too obscure - what do the words

even mean?
Imagine that you meet up with an old friend who knows
nothing about Agile or Scrum. You say “Guess what - I got a
great job as a Scrum Master!” What would she think you do?
Play rugby, taste cakes to ensure they are scrummy, or master
a disorderly crowd of people? The name is intentionally
7
Scrum Master is a Strange Job Title (but we don’t have a better one) 8
obscure, and the chapter on What Do You Tell Your Mum You
Do For A Living talks about the confusion it has caused our
families.
Too specific - do we only do

Scrum?
“Scrum Master” can even cause uncertainty for Scrum Mas-
ters themselves. The title is fundamentally linked to the Scrum
agile framework but is being used more and more to describe
similar roles in agile teams like ours here at NewVoiceMedia
who do not “do Scrum”. Having the term Scrum in the
title could seem too restrictive or intended to scare people
away from deviating from the Scrum framework. This is not
healthy, see the chapter on The Framework Curse for more
on that.
The role “Scrum Master” was created as part of Scrum and
defined at scrum.org in the Scrum Guide¹ and the Scrum
Glossary.
Scrum Master: the role within a Scrum Team

accountable for guiding, coaching, teaching and
assisting a Scrum Team and its environments in
a proper understanding and use of Scrum.²
When you say “Scrum Master” do you mean what the Scrum
Glossary says it means? Does it matter? Usage (and under-
standing) vary a lot. This can be a blessing and a curse.
¹Sutherland, Jeff; Schwaber, Ken. “The Scrum Guide”(TM). 2013.
http://www.scrumguides.org/scrum-guide.html
²The scrum.org glossary: https://www.scrum.org/Resources/Scrum-Glossary
When you take a new job as a Scrum Master it can be unclear

what will be expected of you. Even after you have been in the
role for a while other Scrum Masters will do things differently.
This flexibility can be a real joy in your work, and some may
argue that the role demands this agility to help the team tackle
any problems that arise.
Even if you do plan to work entirely within Scrum the role of a
Scrum Master is not only to enforce the framework, so why is
that the only thing you are a ‘Master’ of? Probably the worst
thing about the title is the ‘Master’, how very arrogant.
Why do we use it then?

Like the Scrum “artefacts” and “ceremonies”, the name Scrum
Master was chosen deliberately to be different from any pre-
existing business role. This was so that people would be less
likely to fall back on older behaviours expected in roles with
familiar names.
Scrum was defined and being used successfully from 1995,
even before agile became “a thing” in 2001 in the Agile
Manifesto. Now, in 2016 Scrum is the dominant agile method³.
Many people working in an agile process only have expe-
rience of Scrum and use the words Scrum and agile inter-
changeably. They understand what a Scrum Master is, and
probably would be confused if you used any other name.
Here at NewVoiceMedia we recruit for Scrum Masters to work
in our teams. We think it is the most widely understood term,
³Version One create and sell support tools for agile working. Of the people who
responded to their 2015 “State of Agile” survey, 70% reported that they use Scrum.
http://stateofagile.versionone.com/
even if not the most accurate. However, even in this case we

find a wide variety of expectations in the people that apply
for our roles. But we can’t convince ourselves that there is a
better name.
Alternatives
There are other titles used to describe our work. How would
you judge these alternatives? A title that does not include a
specific framework that we don’t use? A title that does give
a clue to the work that we do? Should it include the most
important part of our work, or say who we work with? Or
should we stick with the same name as most other people use,
the most widely understood?
Here are some titles we’ve seen used elsewhere (and the
number of Monster.co.uk hits for each term today in 2016)
- what’s your favourite?
• Scrum Master (433) Widely understood to be generic,

despite the inventor’s claims.
• Team Coach (201) We work in a team, we do some
coaching, but is it too general? Who would look for a
job as a Team Coach?
• Agile Coach (48) Generic, and we do some coaching,
and we are agile (but is that too specific as we work
with ideas from outside of agile too).
• Process Coach (26) We coach on the team processes,
and perhaps this title is a little more relevant than team
coach.
• Flow Master (0) I’ve seen this used in the Rolling Rocks
Downhill book⁴, and in Kanban from the Inside⁵, but
I’ve never met a Flow Master in real life.
⁴Ching, Clarke. “Rolling Rocks Downhill: The Fastest, Easiest, and Most Entertaining
way to Learn Agile & Lean; The Agile Business Novel”. 2016. http://www.rolls.rocks/
⁵Burrows, Mike. “Kanban from the Inside: Understand the Kanban Method, con-
nect it to what you already know, introduce it with impact”, Blue Hole Press. 2014.
http://www.djaa.com/kanban-inside
How to Tell People
What to Do Without
Telling Them What to
Do
Being a Scrum Master can sometimes come with the miscon-

ception that you are there to tell people what to do. That is
definitely not the case.
As mentioned previously in this book, as a Scrum Master you
are there to help each member of the team to be the best
12
How to Tell People What to Do Without Telling Them What to Do 13
version of themselves. To be the agile expert for the team.

What we’re not, is in charge. We’re not in the business of
telling people what to do and when to do it and we’re not in
charge of anyone.
So now you can see the dilemma we’re faced with. Sometimes
things just have to get done, so how can we help make it so…
Get the team excited about the

work
One of the key things we can do as a Scrum Master is to get
the team on board and excited about the work they are doing.
The more excited the team are about the work the easier your
life will be.
The Product Owner plays a big part in this role. Like a Scrum
Master, the Product Owner is not in charge, they’re not the
boss. BUT they are responsible for getting the team on board,
up to speed and excited about the work.
Sometimes the Product Owner will need coaching in this area,
so as a Scrum Master it’s our job to support.
Make sure you have a project kick off session, work on these
to make them enjoyable and high impact. A good kick off can
make all the difference.
Every person is different

Something you need to remember is that everyone is different.
This is a good thing, but you need to realise how to deal with
some of the more common personalities.

Welcoming work - there will be those people in the team
that welcome work with arms wide open. This is great, but
be cautious because hand holding and dishing out tasks can
reduce learning. Make sure those who are just picking up tasks
understand the wider context as well. Guide them to come to
decisions themselves, don’t just keep giving them work, no
matter how tempting it is.
I’m not doing that - then there are those in the team that
will need a bit more guidance and convincing. For this type
of personality you will have to work hard on getting them
on board. Make sure they’re brought in on the project at the
beginning and have influence over the decisions being made.
The more empowered people feel, the more they are likely to
enjoy the work they are doing.
Ask them if they agree with the proposed work, if not how
would they do the work?
Put the ball in their court.
Let the team fail

This has to be managed carefully. But you can just let the team
fail and if they are not picking work up, don’t say a thing. Just
let it play out. By doing this, you will miss your sprint goal or
notice stories hanging on the board for a long time.
Now the tricky bit starts. You need to address this at the next
retro. Remember it’s not a blame game but you need to work
on getting to the root cause on why the work isn’t completed
or picked up. Once you’ve got to the root cause then you need
to work out the best course of action for change. Make sure
everyone is happy with the change and then track.
Use the people at your disposal

Don’t forget to use those in the team to your advantage. Guide
the Product Owner into being more influential with the team.
Guide the senior team members to pick up good working
habits and influence those more junior than them.
Just do it
If all else fails then there’s always the more direct route of just
telling someone that something needs doing.
How Do You Become
an Expert in a Room
Full of Experts?
Apples and oranges. Your expertise is different to your team’s exper-

tise.
Welcome to your new team - they are all great people!
16
How Do You Become an Expert in a Room Full of Experts? 17
A room full of experts

Starting work in a development team here at NewVoiceMedia
could be a little intimidating. The culture and hiring process
supports continuous feedback, questioning of usual practice,
and sharing of new ideas. All are great tools, and your new
colleagues will likely use all of them. Maybe together they
will do all of them at once.
You are new here, ready to lead this group forwards in their
self-organization and continuous improvement. How do you
earn the respect to motivate them on this journey?
The challenge
They have been working together for some time. They know
what they do, and might be experts in their own domains.
They know that they work in an agile process, and they
are used to it. To them agile might mean sprint planning,
retrospectives, and story points. Easy, right? Why do any
more?
You are, or you are becoming, an expert in agile working.
You are also building your knowledge in the broad range
of concepts that underpin agile ways of working, and some
different agile processes. How can your team benefit from
your expertise without you distracting them from work that
they are here to do?
Ways forward
Listen and understand

It can take some time to distinguish the clever from the lazy
or mis-guided. Why does your team not use a story point
burn down chart - do they have some other better metric?
Should they have one? Why don’t they look at detail in sprint
planning? When do they do the design work for a new story?
How do stories evolve before they are started? How long does
it take for the team to finish work? Do they know?
Sometimes context will determine what is appropriate, other
times the team might have just slipped in to a bad habit.
Lots of columns on whiteboards, feature toggles, development
toggles, trunk based development, no sprint commitments, no
diagrams on the walls, no sprint reviews, no metrics, no need
to talk to people outside the team, always keeping busy with
productive work. Does any of that seem odd? Ask someone in
the team if they can explain it. Then ask someone else. Share
what you learn back to the team. Do they agree?
Don’t try to prove that you are an expert

Depending on your background you might be able to join in
the technical discussions and arguments in the team, but that
is not why you are here.
Perhaps some or your colleagues are enlightened and have
taken an interest in development processes and principles.
They might cherry pick agile principles to support their own
course of action or inaction, or bring alternatives to your
suggestions. It would be a distraction to your team if you try
to win arguments about the topics that you are an expert in.
Instead explore your colleagues’ ideas. Look underneath the
changes that they are suggesting or resisting. Why are they
challenging you?
Make problems visible

Make problems more visible before trying to point them out,
and before offering a solution. Perhaps the right metric will
show how the team can do better and track improvement.
Perhaps stakeholders can be brought in to conversations with
the team to broaden the teams’ understanding of their work.
Perhaps retrospectives and looking for root causes will help.
Hopefully clear problems will emerge, and solutions are often
then obvious to all.
Understand the needs of the different roles and people in the
team. Are the product owners needs met? The teams’ needs -
testers and developers? How can the rest of the team support
them better? How can the rest of the team learn about these
needs?
Build consensus, build trust.

Have fun!
Keep looking for unhelpful behaviours inside and outside of
your team. Keep pointing out the successes. You’ll do great,
and you’ll become an expert in the team and the way that
they work!
What Has a Scrum
Master Ever Done for
Us?
I did some numbers recently and I reckon I have spoken to

nearly 100 Scrum Masters in the last year or so whilst we were
recruiting. One of the questions we ask is: What does an ideal
team look like to you?
After 100 versions, many of the answers are predictable.
A self-organising team made up of T-shaped⁶ en-

gineers and testers. Everyone is co-located with
⁶https://en.wikipedia.org/wiki/T-shaped_skills
20
What Has a Scrum Master Ever Done for Us? 21
their dedicated product owner sitting alongside

them.
Really? So if your team is awesome, multi-skilled and self-

organising, what are you going to be doing as a Scrum
Master?
I will be protecting the team from the business

and removing impediments. Obviously I will be
facilitating the ceremonies too.
Sigh. It’s not that these are bad answers, it’s just that they
are uninspiring. They are also not deep enough. Let’s explore
them and I’ll show you what I mean.
Protecting the team

From whom are you protecting the team?
The usual response is that the team needs to be protected from
people interrupting the sprint in progress.
In my experience, it is only in an organisation early in their
agile adoption timeline that a team requires this.
Mostly I’ve just needed to protect the team from themselves.
In the wrong circumstances a team might ‘inspect and adapt’
themselves right back to the waterfall process they were
hoping to avoid. This is your real enemy; the human nature
of the team.
Have you ever facilitated a great retrospective where every-
one has committed to try new practice for a few months?
After a week or two, they forget, or stop doing it because it’s

hard.
Your job is to help those team members stick to their com-
mitment - we all finding building new habits a difficult thing
to do. You are protecting the team from themselves, from the
tendency of human nature to pull each of us off the path we
actually WANT to be on.
Removing impediments
Finally, if you are removing impediments in the early days of
your team, that’s great. You are freeing up the team members
to do what they are best at. You are also working out where
the waste in the process is, and forging new paths of co-
operation with other teams and departments. You are setting
an example, and showing how things can get done.
Over time though, you should be actively encouraging your
team to be removing their own blockers. Nothing you do as a
Scrum Master in your team should be viewed as permanently
‘your’ job.
Celebrate your redundancy

The end goal of a Scrum Master is to effectively make them-
selves redundant for their team. If the team is T-skilled people
with skills in areas other than their speciality, and they self-
organise effectively, then your Scrum Master job is done.
Walk away and spend your energy and skills elsewhere.
Some people haven’t experienced the awesomeness of work-

ing with a great Scrum Master. Some people see the Scrum
Master role only takes 15 minutes work each day at the stand
up for 9 days out of a two week iteration. On the 10th day,
they facilitate the show & tell, the planning session and the
retrospective of course. One day a fortnight hardly seems like
a heavy work burden to them. This is how the Scrum Master
role ends up being done poorly. The role will be filled by a
developer or tester who would still rather be a developer or
tester than a Scrum Master.
As a result they fulfil the basic ceremony requirements, but
lack the desire to learn about human psychology. They aren’t
interested in improving the process, nor training the team in
further agile ideas. More unfortunately they want to be in the
detail (as a developer or tester) not step back and look at the
overall flow of the work.
As Scrum Masters, we then make this perception of workload
worse. It is a cruel fact that the better a Scrum Master is at
being a Scrum Master, the less they look like they are working!
The best Scrum Masters look like they are wandering round
the office, having chats and drinking coffee. But then, no one
said life was fair.
You’re Not the Admin
Lacky
Admin will drag you down
As a Scrum Master it is in your nature to do everything you

can to help your team. This is a great attitude, but be careful
not to become their admin lacky.
Let us start by detailing what these admin jobs are. Story
creation, not your job! Moving tickets, not your job! Scribe,
not your job! Tracking who is in work, not your job! Making
everyone tea, not your … well maybe sometimes. If you do
24
You’re Not the Admin Lacky 25
take on the admin tasks for an extended period of time, it will

become your job. It is not your job!
Maybe you are okay with it being your job, the problem is
it will make you worse at what you are there to do. A good
example of this is note taking during a planning session. Your
constant scribing will mean that you’re unable to take in
what is said and ask those difficult questions which are so
important and key to your role. Your other risk is that those
around you will think it’s your job, and it will only get harder
and harder to break the cycle.
A common task the Scrum Master may end up taking on is
moving tickets on the digital board, or post-its on a white-
board. That is a bad idea. The process visualised on the board
exists to help understand the work. But it also encourages the
person that is working on the task to ask themselves some
questions. For example when someone moves a ticket into the
‘In Progress’ column, they consider the story details and if it
is ready to work on. If you move it for them, they are less
likely to ask these questions.
One of your most important responsibilities as a Scrum Mas-
ter is to coach the team. If you try and do everything for
the team, you are not helping them. The age old quote seems
pertinent here:
Give a man a fish and you feed him for a day;

teach a man to fish and you feed him for a
lifetime
Just replace the word fish with agile, and feed with guide. You
get the idea.
You’re Not the Admin Lacky 26
You do have a holiday entitlement (I hope). If you are the

person that takes on all these admin tasks, what will happen
when you go on holiday? It will all ‘go to pot’, but you don’t
care, you’re on holiday after all. But you do, that is why you
are a Scrum Master, so consider the consequences.
Sometimes it is okay to do the admin. One of these occasions
is when you join a new team. It is risky to try changing
everything immediately, you need some time to get a baseline.
While you do this observation it’s a great time for you to help
with the team admin (but not too much, see above). It will
help build trust between you and the team. When the team is
under pressure is another good time to step in and help, they
will appreciate it.
Being Effective and
Liked
It’s like a circus act
This constant battle is important, and probably healthy. Some-

times to be effective you have to sacrifice being liked, and
this conflict runs deep. It is natural and instinctive to want to
be liked by those around, if you don’t you’re a special type
of person. Your ability to be effective and liked can be like
walking a tightrope.
This is a common challenge for Scrum Masters and depending
on your personality and experience, your ability to manage
this will vary. The role in its nature demands both the need for
effectiveness, and often to achieve that, the need to be liked.
So yes, we all want to be liked. But, and it is a big but, you are
27
Being Effective and Liked 28
not paid to be liked. As a Scrum Master you cannot get away

with shying away from problems, it is your job to confront
them. That is what makes you effective.
When talking about this exact problem Todd Henry captures
the difficulty perfectly:
You can be both, but you can’t chase both at the

same time
In short, chase effectiveness in a way that people will not

dislike you. That is our ideal, and here are a few films to help
you achieve that.
The Illusionist
Self discovery is the holy grail. If you can shine a light on
a problem in a way that allows the team or individual to
spot the problem, your chance of success will be dramatically
higher. They might even still like you at the end of it. The
retrospective is your perfect opportunity for this. You can
even influence the team into talking about the problems you
want.
A Series of Unfortunate Events

If you are struggling to encourage self discovery a good
technique is to let it go wrong. Once the team has made a
mistake it is much easier for you to highlight the problem.
But remember no pointing and saying ‘I told you so!’
Being Effective and Liked 29
Braveheart
The key thing to remember is that you are chasing effective-
ness. On occasions you will have to be bold and blunt. Maybe
someone is constantly interrupting the team with work out-
side the sprint. Tell them straight, this is not acceptable. The
team need FREEDOM to work.
New Team Members
Adopt the Same
Behaviours as the
Team
Most Scrum Masters during their career will work with teams
that are dysfunctional.
These teams may not have gelled together yet and are still
forming. Or the team may have deep rooted personal chal-
lenges causing conflict and uncertainty. Or they may be
working on technical issues that are grinding people down.
Teams are dysfunctional for many reasons.
It is hard work turning around a team, but it is possible.
It can also be easy to assume you can change the team by
adding some “fresh blood” to the team. Hiring managers fall
in to this trap of hiring people believing they will change the
nature of the team.
It can work. New people to the team can change the norm,
but it’s not something I’ve seen work often.
New members of the team often end up adopting the existing
behaviours of the team.
30
New Team Members Adopt the Same Behaviours as the Team 31
I’ve seen positive and optimistic people join teams with low
morale. They become zapped, drained and a shadow of their
former selves over time.
I’ve seen strong agile advocates join teams that are hell
bent on resisting agile. The advocates become disillusioned,
frustrated and bored.
I’ve seen testers determined to bring new ideas about testing
to the team, only to find every idea shot down in flames.
To turn around a team work with individuals in the team
and listen to them. Try to understand why the team is not
working. Use feedback and coaching to try to change the
ingrained behaviours that are problematic.
A lone individual may be able to do this.
A Scrum Master may be able to do this.
New Team Members Adopt the Same Behaviours as the Team 32
Depending on how problematic the team is, you may need to

involve managers too.
Try to adopt a positive attitude when trying to change a team.
But don’t assume a strong minded individual can change an
entire team.
In my experience new team members adopt the same be-
haviours of the team.
This is the Team to Get
it Done
As a Scrum Master it’s important you feel like you’re in a
team that can get the work done.
As work flows to your team it’s important that you feel

confident saying “This is the team to get it done”.
If you are in a team that isn’t “the team to get it done” then
why is that?
What is missing from the team? Why is this work not right for
your team? Are you missing skills, experience or leadership?
33
This is the Team to Get it Done 34
Why is this not the team to get it done?

By answering this question through studying the work and
the team you’ll hopefully identify what’s missing, or what the
blocker is. With this knowledge you can then move forward
with actions and plans.
These actions and plans should lead you to the point where
you do feel confident saying “This is the team to get it done”.
Using Small Steps
When Big Changes
Might Be Resisted
A bear, resisting change.
If you know that the world could be better, how will you start
changing it?
35
Using Small Steps When Big Changes Might Be Resisted 36
Think big
As a Scrum Master you are learning how your team works
with each other, and you are learning how the business works
with your team. You are learning the expectations that your
team mates have of each other. You are learning what the
business expects of your team, and what your team expects
from the business. You take time to work with colleagues to
understand what our customers expect of the business.
From your perspective slightly outside of all this you will
see that we are making things too hard. Our work could be
simpler, or work might be avoided completely. How should
you start to solve the problem that you can see without
resistance from the people you need to help you?
Know your true north

If you can see a problem, then how could the world be better?
Think about the way the world could be, don’t worry yet
about what you might do to make that happen. Think of this
better world as your true north - the direction that you want
to follow even though you must sometimes go off-course on
the way.
Act small
If you can see a big problem, and you have a vision for what
would be better then you probably want to go about changing
things. Making any change can be disruptive, and the bigger
the change the more disruptive. This is because people must

adjust to new ways of working and new responsibilities.
When we start to change a system the J-curve model tells us to expect

an initial dip in the capability of the system.
If your company CEO supports the change and will be patient

during the likely dip in performance then a “big bang” might
be a fast way to improve. If your large change is not the CEO’s
pet project, or the CEO is an impatient person, then you might
choose to break your change in to smaller steps.
Big ideas can have big consequences. No matter how con-
fident you are, are you sure you have your team’s support?
How long for? Commit to safe-to-fail experiments, and pay
attention to the results.
Evolutionary progress towards a significantly improved process - a

series of small J-curves.
This evolutionary approach can be more inclusive to benefit

from a wider range of inputs and the learning after each small
change.
We are not working alone

As a Scrum Master you’re not likely to be making any changes
on your own, and usually the changes aren’t to help you. You
are suggesting that someone else’s process could be better.
Despite your good intention they might take this as a personal
judgement of their current performance.
Self-image and identity

Respect other people’s roles and experience. Depending on
the scale of change being proposed identity can feel under at-
tack in many ways. For example, moving to a cross-functional
team can be hard. Perhaps a career has been built within a
specialist department. People might have achieved status and

authority in that role that does not clearly transfer in to an
agile cross-functional team.
At a smaller scale any request that someone change their
behaviour could feel like criticism, not a boost for self-image.
Some personalities do not naturally welcome change, leaving
people uncomfortable or confused. Should we be surprised
when some people do not rush to support our grand or humble
proposal?
In all these cases you can reduce resistance by avoiding
surprise, moving tentatively, being open about intent, sharing
data, and looking for feedback and suggestions throughout
the process. You will improve your own understanding in the
process, and be given better ideas than those that you might
have proposed on your own.
Is the reason for the change

understood?
Nobody likes being told what to do, but everybody would like
to do a great job. How can you raise the profile of the problem?
Do stakeholders get the opportunity to talk with the team? Is
the product owner communicating with the team effectively?
Are team members sharing their frustrations with each other
clearly?
Is there an important metric that illustrates the problem? Are
the team aware of it, and able to affect it?
Science
Listen for good ideas, identify helpful measures, and help
design safe to fail experiments to improve. The more personal
to you, the smaller the experiment should be. Decide what
“success” looks like before you start your experiment, make
your change, and then wait to see if it was as expected. What
can you learn from the new situation?
Make your next step

If you keep your true north in mind then lots of small changes
will add up to big progress over time. What are your true-
north goals? What small steps can you take towards them?
Start from where you are, know where you could be, and be
respectful of roles and personal identity on the way.
Tools to use
• Systems Thinking
• Toyota Improvement Kata
• True-North Goals
• Plan Do Study Adjust
• Kanban improvement process
Why is Coffee
Important?
Let’s get a coffee…
We have all heard of phrases such as “Let’s walk and talk”,

“Give me your elevator pitch” or “Let’s get a coffee”. When
someone comes up to you and says “let’s get a coffee”, you
instinctively know that you are about to have a conversation
with this person.
Your reaction might depend on who is asking this question. If
your HR manager comes to you out of the blue and asks you to
join them for a coffee, you better make sure your CV is nearby.
If this is your colleague with whom you play Dungeons and
Dragons, you can breathe easy. It maybe that they are excited
by a new character being released and can’t wait to talk about
41
Why is Coffee Important? 42
it. So where does a Scrum Master fit into this?

Have you ever met a Scrum Master who asks you if you’d like
to join them for a hot drink? And if they’re rad, for a beer?
Whenever and whoever I ask this question to, the answer is
always “Yes”. This does not mean that Scrum Masters like
having a lot of drinks. No, it’s just one of the commonly used
weapons in their secret arsenal.
If you ever observe carefully, you may actually find a pattern
in the invitation for a drink. You will find that Scrum Masters
will extend this invitation either before or after an event.
Let us examine this. Some events, such as a painful planning
session or a heated argument at stand-up, trigger alarms bells
in the Scrum Master’s head. He or she may decide to approach
the entire team or individuals about the events. In the case of
an individual approach, a conversation over a coffee is much
more beneficial than in a formal meeting.
There are many other reasons for conversations over a coffee.
As you have read in this book so far, a Scrum Master’s role
is varied and broad. Servant leadership, resolving conflicts,
communication, agile lead are just some of them. For each
one of these responsibilities, it is important to be able to un-
derstand every member of your team. A Scrum Master needs
to be able to understand what motivates and encourages
the team members whilst also being aware of what hinders,
scares or worries them. To be able to do this, a Scrum Master
spends time with the team observing and analysing their
conversations, processes, success and failures. The next step is
to establish one-to-one relationships. To do so, Scrum Masters
often go ‘for a coffee’ with the individual team members.
Why go somewhere for a coffee you ask? Let me tell you why.
Going somewhere else other than regular meeting rooms or
Why is Coffee Important? 43
working areas creates a sense of privacy and friendliness. It

reduces formality and a sense of apprehension or unease that
may be associated with it. People involved are not restricted
by their surroundings and can freely interact with each other.
This helps in many ways. It can help create a good profes-
sional one-to-one relationship. It allows people to talk freely
without having to worry about what others may overhear.
Last but not least, it helps build trust.
For many of us, having a morning coffee is part of our daily
ritual. For some this extends into the workplace. In many
cultures offering a coffee is considered as being respectful.
Similarly your Scrum Master may offer you a coffee, for all,
some or none of the reasons described above. Enjoy it!
Being Flat Out Busy is
Not Effective Agile
44
Being Flat Out Busy is Not Effective Agile 45
Going slow to go fast

We have all heard of this quote. If you are anything like me,
you may have used it many times too. Technology, and with
it our world, is changing at a rapid pace. It is not going to
slow down either. If that’s the case, why is it bad to go fast?
Surely we need to catch up with all the changes, don’t we?
The answer is a simple “no”. Let’s understand why. Being busy
doesn’t mean being productive.
Speed
Most people confuse operational speed (time taken to com-
plete a task) with strategy speed (the time taken to deliver
value). Being fast at operational speed will not necessarily
yield good value in the long run. But going fast at the strategy
speed will do. Increasing the speed of production may appear
to be delivering more items but it is only going to slow us
down later on. If we are improving and getting faster at
reducing the time taken to deliver value then even a smaller
number of items moving through production will produce
greater value. This is because when we slow down we can
take time to understand what is most valuable to be delivered
first.
Reflection
If the only constant in your sprint is delivering items at a
fast pace, then you are likely to not have any time to reflect.
Every team needs time to reflect on their achievements and
disappointments. We know that from this reflection comes

the learning which is invaluable to the team. Being agile
means to be able to improve, learn and adapt based on our
performance. It is important to pause at key moments to take
stock. This will help the team to make sure that they are on
the right track.
Quality
When teams work without slack their focus on the big picture
gets jaded. They will not be able to keep updated with the
changes being made to this big picture. Ironically they won’t
be agile enough to adapt to this change. Ultimately this will
result in undesired or incomplete features with poor quality.
Lower quality means lower value delivered. This lower qual-
ity will add more work to the team backlog in the form of
bugs and issues. The team then spend time on fixing these
bugs instead of working on higher value items. You see the
vicious circle here, don’t you?
Not sustainable
We adopt agile practices with the aim of improving consis-
tency and for the ability to deliver frequently and iteratively.
If the team are concentrating on being fast with operational
speed, then in the first few sprints they will deliver a lot
of items. But over time they will be exhausted by working
without slack. This exhaustion will result in a drop in pro-
ductivity and the team will deliver fewer items. They may
continue to deliver iteratively but this will not be at their
best. This may result in a low morale in the team. Burnt out
frazzled employees are not likely to be happy and may leave
the company. This is a massive loss for the company as it will
lose good employees and spend loads on recruitment.
The Framework Curse
Consider them all
If you are reading this book you probably describe yourself as

a Scrum Master. Does that mean you only do Scrum? Maybe,
but probably not strictly.
There are more ‘agile’ methodologies than you can shake a
48
The Framework Curse 49
stick at. Here are a few named in the Version One State of
Agile Report:
• Scrum
• XP
• Kanban
• Scrumban
• DSDM
The important thing you need to remember is that these are all
just tools. With any tool there are advantages, disadvantages,
and bits that just don’t work for you! Just because your label
is Scrum Master you do not have to only follow the Scrum
methodology to the letter. In fact your job demands that you
do not. No framework suggests bribing the team with cakes
and sweets, but we all do that.
Your role is to help the team spot, understand, and fix prob-
lems in their process. So what if the problem is with Scrum
itself? A common anti-pattern of Scrum is that work is rushed
to completion at the end of a sprint. This happens because the
team has committed to the work, and no one wants to fail. The
downside is that your quality will likely suffer. So you could
try and solve this within the Scrum framework by bringing it
up in the retrospective or reducing the work in the sprint. But
what if that doesn’t work? Why not consider borrowing from
another tool? Scrumban for example, where work is allowed
to flow between sprints.
A good place to start is to pick the framework you (and the
team) are most comfortable with, and iterate on that. When
you hit a challenge ask yourself can we solve this in ‘Scrum’,
and if not, how can we solve this another way? Stealing an
The Framework Curse 50
idea from another framework is a great start, or maybe you

have to discover your own solution.
You should aim to keep these changes small and at least a
couple of iterations apart. Although Heraclitus said “The only
thing that is constant is change”, it sure can be exhausting.
It will also make it difficult to measure if your change was
effective.
Warning! Don’t get too carried away merging every frame-
work into your own super framework. The approach is good,
but it must target a given problem you are experiencing. You
should not underestimate the advantages of a recognisable
structure to your process. Just with a few tweaks.
The Kind of Person
Who Knew Too Much
Learning and studying are essential to personal growth. This
personal growth helps individuals become more competent,
but it also helps the company to achieve better results. This
only works if the person doing the studying then puts in to
action what they are learning.
There are too many people in the agile world who know a
lot about the theory, but have never put it in to practice. You
know, the kind of person who knew everything about pretty
much everything to do with agile, except the agile world they
51
The Kind of Person Who Knew Too Much 52
are living and working in.

It’s fine to have theory. In fact, we work from a lot of
theory, but we experiment. And that’s what I’d encourage
you to do as a Scrum Master. Read something, understand it
and then test it, but only if you have a problem that needs
solving. Through this experimenting process you’ll gain a
deep understanding of what works and what doesn’t. You’ll
be able to fine tune it, mash it together with something else
or ditch the theory all together. At least by experiencing it
you’ll gain knowledge. Without testing out the theory all you
have is a theory, some information, someone else’s story of
success.
A critical mind is essential for scrum mastery. What works for
one company might not work for you. Don’t trust the theory
until you tried to apply it - it might not work. There are no
such things as Best Practices - just relevant judgements.
Try not to be the Scrum Master who knows a lot of theory but
can’t solve the business’ problems.
No Process is Perfect,
but it Doesn’t Mean it’s
Crap
Process: a series of actions or steps taken to

achieve a particular end.
As the agile manifesto⁷ states, we should “value individuals

and interactions over processes and tools”.
⁷http://agilemanifesto.org/iso/en/
53
No Process is Perfect, but it Doesn’t Mean it’s Crap 54
As a Scrum Master this can cause some discomfort. Especially

those that have come from a Prince2 waterfall background
where process is always on the heavy side. What you’ll find
though is that no two teams are the same.
In my experience there are two extremes. The first is utter
chaos with no process set that any team member understands,
yet alone follows. I’m sure you’ve all experienced something
like this before. Nobody quite knows how stories are created
and how they are flown across the board or how deployments
are made or bugs are fixed, you get the picture.
The second is process paralysis which is complete control
and death by process. Team members become scared of going
outside of the process in case of being ridiculed by others. Plus
anything that goes wrong is blamed immediately on a slight
process deviation.
You’ll be pleased to know that there is a happy productive
medium. A place that can please both sides of the spectrum.
The key to it is building a process WITH your team and not
pushing process on them.
As the title states, no process is perfect but just because your
processes aren’t perfect it doesn’t mean they’re crap.
Here’s a list of things to remember to help stay on top of your
processes:
• No process is perfect, so make sure you iterate on the

ones you have.
• Don’t over process. Only create processes where neces-
sary.
• Make sure your processes are based on real life scenar-
ios rather than the ideal scenario.
No Process is Perfect, but it Doesn’t Mean it’s Crap 55
• Don’t create processes on your own, create them with

the team.
• Share your processes. Particularly with new starters as
they can help with onboarding.
• Don’t go Tech. In the past I have used post its on an A3
bit of paper. You don’t need the latest bit of software.
• Make sure your processes are accessible to the team. In
a shared folder, or even on the wall.
• Keep the language basic (if you can).
• Processes are there to help people. Keep them simple
and to the point.
My closing statement is to not be scared of processes. At the

end of the day they are to help people.
So make sure the people that will be using the process have
fully bought into it, understand it and feel they are empow-
ered to change it if necessary.
Poor Requirements
Poor requirements are often blamed for poor work.
Poor requirements are often blamed for late work.
Poor requirements are often blamed for people building the
wrong thing.
However, the requirement didn’t wake up one day and decide
to ruin your sprint or project. At no point during any failed
process is the requirement at fault. It’s inanimate. It doesn’t
exist. It’s just a model. It’s got no feelings.
We’ve worked hard to make sure that shady requirements are
less of a problem. How? By making people aware that the
requirements are not the problem - people are.
56
Poor Requirements 57
People write requirements. Software exists to solve problems

or enhance abilities. The solutions to the problems (etc.) are
usually defined as requirements. These requirements then
flow through your business and the final product emerges.
At no point during this life-cycle is the problem anything to
do with the requirement. It’s all to do with the people. You.
The team. Everyone involved.
Why?
• People define the requirements

• People review the requirements
• People agree the requirements
• Some people don’t question the requirements
• People build the requirements, test them and ship them
• People accept the requirements
Poor Requirements 58
• People build their companies and departments around

the flow of requirements - sometimes incorrectly. This
re-enforces the potential dysfunction and pushes bad
work further through the system.
• Some people ignore the requirements
• Some managers don’t empower their team to challenge
requirements
• Some people put hitting a deadline above getting the
software right
It’s the people (and the system they work in) that causes the
effects.
The people are part of the problem. But that’s good news.
Because once you know that people are part of the problem,
then these same people are also part of the solution.
Reduce Failure
Demand
To make process improvements start to observe and study
where the work demand is coming from.
• Who generates work for the team?

• Where does the work come from?
• How frequent is the work demand?
• How predictable is the demand?
And how much of this demand is work that you didn’t

get right first time, or didn’t even do? This is important to
understand.
59
Reduce Failure Demand 60
John Seddon⁸ defines this work as “Failure Demand”. The

failure to do something, or to do it right for the customer.
You see failure demand in all software development teams.
How many bugs do we work on that we could have avoided?
How many features do we build out because our Minimal
Viable Product was just too minimal?
How many features do we build that generate failure demand
elsewhere in the company? For example, extra administra-
tion, support calls from confused customers and problems in
live.
This demand may not be visible and problematic for you, but
it may be plaguing another department.
Digging deep will give you knowledge about your work.
⁸https://en.wikipedia.org/wiki/Failure_demand
Reduce Failure Demand 61
With knowledge you can make informed decisions on how to

reduce failure demand. With knowledge you can build your
process to support value demand.
Once you know how to study for failure demand, how to
reduce it and how to build a system to support value demand
- you will see output from your teams that you once thought
wasn’t possible.
Inflicting Help
62
Inflicting Help 63
A Scrum Master is a true servant leader. Examining the roles

and responsibilities of a Scrum Master makes this clear. This is
further explained in the chapter What Has Our Scrum Master
Ever Done For Us? With this in mind, is it ever possible for a
Scrum Master to cross the line from being helpful to inflicting
help? Let us find out.
Being helpful
By the nature of the role, Scrum Masters are helpful. They
are in place to remove any impediments that may stop the
team from functioning well. They help the teams to achieve
their goals. To do all this a Scrum Master has to be able to
identify scenarios where help is needed. Once identified, a
Scrum Master then extends their help to the team. The help is
accepted and the problems are solved.
Another scenario is where the team approach the Scrum
Master asking for help. The Scrum Master agrees, and the
team’s problems are solved.
Great. So far so good.
Inflicting help
The problems begin when a Scrum Master goes beyond the
above and starts to impose help on the team. There are many
drawbacks to this.
Inflicting Help 64
Giving the answer is not learning

In a scenario where the Scrum Master has identified a prob-
lem, the Scrum Master should then not try to solve it for the
team without them knowing or accepting the help. As shown
in the chapter You’re Not The Admin Lacky, if a Scrum Master
doesn’t let the team make mistakes, the team will never be
able to learn from them. This is not to say that you step
back and watch them fail. Once the team have gone through
a difficult task or period, the Scrum Master can help them
reflect on it and gather learnings. It will only make the team
stronger. It’s all about discovery.
Not knowing that you are inflicting help

Sometimes you may spot a problem that if left alone will turn
into a nightmare. It’s something that you can fix. The team do
not even need to be disturbed with this problem. You fix it, go
to the team and present the solution. You expect the team to
thankful. But, the team are not happy. What has gone wrong
here?
In this scenario, you have unknowingly inflicted your help on
the team. If you had presented the problem before fixing it, the
team may have wanted to fix it differently. Or they may even
decide to not fix it. They might have a good reason for doing
so which you may not be aware of. By fixing it for them, you
have not only ignored them, you may have actually made it
worse.
There will be circumstances when the team will want to
discuss ideas between themselves. You do not need to be part
of every conversation. They will always come to you when
Inflicting Help 65
they need you. Or you can ask them on their progress if you
really need to know what is happening. By inflicting help, you
may even create animosity and resentment towards you.
“To help or not to help?” that is the question
Always help. But only when your help is requested or when
your offer of help is accepted.
Helping doesn’t mean that you do things for team. You should
offer options to a solution and let the team choose. You can
even ask questions to drive them towards a solution. Ask
questions such as “Have you done this before?” or “What is
different in this approach?”
As a Scrum Master you are there to help the team grow
and become a self-organising team. To get there, they will
inevitably fail along the way. They may fail even with your
help. Who’s to say that you know all the solutions? The
problems that the team face today may not be the same
problems that they face tomorrow. By inflicting help and
solving problems without being asked, the team are none the
wiser.
Agile Consultants Who
Don’t Know What it
Means to Be Agile
If you have an agilist mind set and you come up against a

problem, usually you seek out an expert from whom you can
get some advice. Engaging the services of an ‘agile expert’
would seem like a sound and sensible move. Unfortunately,
it can be easy to forget that not everyone shares our same
values, so seek out someone who will do the job you want
done well.
66
Agile Consultants Who Don’t Know What it Means to Be Agile 67
What we want from an agile

consultant
We want someone to come in to our organisation and take
the time to fully understand the context and needs of our
particular business. To understand where we are, right now,
before they start changing anything.
We want consultants who exude confidence, and help our
staff to understand and work in this new agile way that we
have heard so much about. It sounds like it would be fun
and fulfilling to work in this way, and we really want to get
software out to our customers more often.
That’s what we want.
What many agile consultancies

will try and sell you
Lots of their people for as long as possible. They will tell you
that this will bring Agility.
They will (without irony) tell you need to do this a little at a
time, so you won’t see too much change in the way you run
your projects at first.
They will promise you that in time, your same team will be
delivering software with fewer bugs, faster and cheaper than
you currently do. They may even offer the idea this will easily
offset the cost of their services in the long run.
They will ask you to pick a project and a deadline, to give
them some of your staff, and they will augment that with
some of their own. They will favour green-field projects

(always easier than learning about existing domain issues).
They won’t want to talk about the roll-out plan until later.
Am I sounding a bit cross? I wish I could apologise and say
that this was not the case but I won’t lie to you.
What we too often get from an

agile consultant
Agile ceremonies wedged into the current process.
35 people at the standups. A senior manager attending each
day specifically to ask “who hasn’t delivered what they
thought they would yesterday?” No one from the consultancy
challenges or coaches him.
No discernible change (never mind improvement) over, say, a
two month time window. If no changes or experiments have
occurred in that time - even if they made things worse, your
consultants are coasting.
Six Scrum Masters from the consultancy will be dropped into
existing, or randomly formed teams. These will not be the
crack force of Scrum Masters you are anticipating, I promise
you. If you are lucky they will be mostly average.
How can we know if the

consultant we are thinking of
engaging is any good?
They should want to know your criteria for success. How will
you decide that they have done their job? If they don’t ask you
this, be very wary.
They should suggest starting small, with a single team, on a
small, non-critical project. This will allow your organisation
to see what agility will really mean for you.
If you are already practising agile working but are looking to
improve, this is a little different than a transformation. Look
for your consultants to show deep curiosity in what you are
currently doing and why. They should ask you what problems
you are having with your current approaches. They should
not be judging what you are currently doing at all.
Consultants should ask your executive team for some com-
mitment towards getting agile training. Your execs need
to understand how things are working and how they will
change. This is important regardless of your organisation’s
current level of agility.
Be very wary if they try to tell you to adopt a particular
practice before spending time in your organisation. Be that
Scrum, Kanban, SAFe, LESS, DAD, Scrumban, it’s just too
early for them to know what will work best for you. Almost
never are all your answers to all your problems (now and
future) neatly packaged up like that either.
If you are introducing agile from scratch though, Scrum is
often a good starting point - that will likely change over time.
Well, this is depressing, is there a

better way?
Yes. Yes there is, but you might not like it.
If your company is serious about improving your agility as an
organisation, hire a great agile coach or Scrum Master.
Not many will take a permanent position, because the best
recognise that it is a temporary role anyway. You are looking
for someone who will be committed to the success of your
company. There are many great contractor coaches, and just
as many awful ones. Word of mouth is best. Find someone in
the agile world who you personally rate, and ask their honest
opinion of who’s good.
They will not be cheap, but then, they are cheaper than
consultants and get better results.
Expect to need to have a coach in place for at least 2 years.
You might be able to wind this down to part time after a year
or so if you have some great Scrum Masters in place by then.
Whoever you are hiring make sure they have bona fide
experience.
Not everyone who says they are agile is being honest. And
not everyone who truly believes they are agile knows what
it really means. They need battle scars of having tried lots of
different things and lived through the consequences.
Last words
There are a few good agile consultancies out there. If you
shout out to the agile community, people will be very willing
to help you with names and experiential stories. Listen to
people you already know, or whose work and opinions you
follow.
If there is only one piece of advice you take from this chapter
it should be this: do your research.
What Would a
Customer Say if You
Shipped it Now?
A good question to ask yourselves for every story you are
working on is “What would a customer say if you shipped it
now?”
The answer to that question will give you some idea about
how close you are to shipping that story.
As you’re building and releasing software it’s important you
start to ask the team whether the story really is good to go, or
72
What Would a Customer Say if You Shipped it Now? 73
is there something not right about it.

What would your customers say if you shipped it now?
If the answer isn’t a “They’d freaking love it” then should you
be shipping it?
Of course, there are a multitude of reasons why you may
continue to ship the software (get feedback, meet arbitrary
deadlines, because someone told you to), but if your cus-
tomers aren’t going to be loving it then are those reasons
really that good?
Whilst Doing This,
You’re Not Doing That
Should we do something about that first?
There is sometimes tension between shipping new features

quickly or doing more work so that the customers will love
our product.
Our business expects a stream of new work from us. The next
project does not get started until we move on from our current
project. But things are always changing. The work we are
about to start next might have become more valuable to the
business than the work we are finishing now.
By releasing often we get more opportunities to change direc-
tion without interrupting work in progress.
74
Whilst Doing This, You’re Not Doing That 75
There is another good reason why we might choose to follow

the advice “release early and release often”: shorter feedback
loops. Our customer knows what they wanted at the start of
the project, but they learn as they use the software. They may
find this is not what they need. When they can get their hands
on our new features they will learn and feed back to us. The
faster we find this out, the better for all of us.
How to plan so that your

customer will love what you ship
At NewVoiceMedia every code commit must be safe to deploy
to live, but we hide new features until they are ready. How
can we sequence our work in a way that the customer can
feed back as quickly as possible?
While the Agile Manifesto encourages us to deliver working
software frequently, it is light on advice for how to do that.
Splitting stories into ever smaller pieces can help us, but only
so far. We might find sequences of stories that need to be
completed together to enable a new feature for a customer.
One way to reduce this problem is to look at a higher level -
don’t split stories, split your goals. Conversations around the
goals are best in collaboration with the business. Two tools
that can help with this conversation are Impact Mapping⁹ and
User Story Mapping¹⁰.
Both of these tools encourage us to think about what we want
to achieve. What impact on the world or behaviour change do
⁹https://www.impactmapping.org/
¹⁰http://shop.oreilly.com/product/0636920033851.do
Whilst Doing This, You’re Not Doing That 76
we want to enable? Any new project might have several goals,

and it can help to consider them separately.
It can also be helpful to consider if we could split each goal
further, in ways that each part is still valuable. The story
splitting techniques described in 50 Quick Ideas to Improve
Your User Stories¹¹ are great. The earlier in your planning you
use them the more useful they can be.
How quickly can you complete something that you can learn
from? Ideally you will enable new capabilities that are desired
by at least some of your customers. They can feed back to you
and guide you better on whether you really met their needs
before you move on.
We must never release software that harms our customer
or our relationship with our customer. However, instead of
worrying about when you will be ready to release, worry if
you have delivered the most important features in the time
you had available.
¹¹https://leanpub.com/50quickideas
Scrum Master - What
Happens Next?
Whether you’ve been a Scrum Master for a few years or

you’re thinking of taking the leap, at some point you’re going
to ask yourself “what next?”
What is the next step on the career ladder for a Scrum Master?
There are a few logical steps for a Scrum Master to take when
they believe they are ready for the next chapter in their career.
One of the most common next steps is to become a Senior
Scrum Master. This involves taking on extra responsibility
77
Scrum Master - What Happens Next? 78
within the Community of Interest (COI).

Some of the extra work involved:
• mentoring fellow Scrum Masters within the COI

• working on budgets
• headcount / recruitment
• scaling / growing agile
• running meetings / workshops across the business.
I have also seen Senior Scrum Masters become line managers

to other Scrum Masters; this has worked well as they share a
common interest.
This is also a great next step if you’re interested in people
managing. People managing is no easy task. So managing
your peers (in a role you completely understand) can be good
place to start.
People management skills can open up more career paths, as
it’s definitely not for everyone.
Life beyond a Scrum Master

The next step after Scrum Master (senior or not) is an Agile
Coach, which in itself has many guises. I see the Agile Coach
broken down into 3 specific areas:
1. Technical Coach - Supporting developers and testers.

Applying test driven development, refactoring, contin-
uous integration and just being close to the code.
Scrum Master - What Happens Next? 79
2. Programme Coach - Working with project and pro-

gramme managers. Agile programme management, scal-
ing/growing agile across an organisation.
3. People Coach - Working with teams on interpersonal
skills, growing teams, training Scrum Masters.
This is based on what I’ve observed.

If you asked 10 Agile Coaches what their typical day looked
like, I’m sure you’d get 10 different answers. This is what
intrigues me about this role.
What I’m beginning to realise, is that there’s a wide scope
of work within the role of the Agile Coach. You can rotate
around the above three areas to broaden your knowledge, or
you can specialise to become an “expert”.
You can shape your career from here.
And next…
After Agile Coach I’m yet to find out. I’m not sure if there’s a
CAO (Chief Agile Officer) role yet, but maybe that will come
in the future.
Of course the world is still your oyster. So if the above
career path doesn’t sound good to you, don’t worry. Being
a Scrum Master is a tough, versatile role, the real next step is
completely up to you.
As my current hero Gary Vaynerchuck says; “You are One
Hundred percent in charge of your life”
How We Learn
To be a great Scrum Master you need to understand human

beings, psychology, behaviour, motivation to name but a few.
In short, if you want to be a great Scrum Master you need
experience. If you want to get your experience in your own
sweet time, go right ahead; learn everything first hand. There
is nothing wrong with this approach, but you’ll need to put
in some serious time.
Alternatively, you can take a short cut. Save yourself a decade
or so by listening and learning from other Scrum Masters’ war
stories. This is true of pretty much everything you could ever
want to learn, not just Scrum Mastery.
Each of the authors of this book have shared their personal
approach to study. These insights might inspire a new way
for you to learn, but we make no promises.
80
How We Learn 81
Helen Lisowski
Where we use ‘reading’ throughout this chapter (and in fact
this book) we know not everyone enjoys reading in the
traditional sense. If this is true for you, there are many other
ways to ‘read’ widely.
Blogs
If you can comfortably cope with shorter, magazine-style
articles, try collecting blogs instead of books. You can get
yourself a Feedly or Flipboard account and build up a person-
ally tailored set of blogs. The bloggers in question will add to
these blogs over time, and you can easily find them all in one
place whenever is convenient. Medium.com has some great
writers contributing there too; just follow some people and
enjoy.
Audio
Alternatively, audio books have really come into their own
lately. If you do a lot of travelling or commuting, try audible,
who usually run a free trial.
In addition the whole podcast scene is really strong right now.
You can find podcasts on pretty much every topic you can
imagine.
Visual
Finally, if ever there was a game-changing tool for learning it
is YouTube. It is just packed with talks on all sorts of things
How We Learn 82
- have a look, create an account, save some stuff that looks

interesting. Start with TED talks if you feel overwhelmed.
Whatever your challenges with traditional ideas of reading,
there is no need for this to stop you learning.
Rob Lambert
There comes a time in your career when you realise that
remaining relevant and employable is important. It’s now that
many people start to take their self learning seriously.
Reading becomes deep studying. Watching, listening, attend-
ing, reading, observing, coaching, mentoring - all forms of
studying and learning.
Studying leads to knowledge. Having knowledge can help you
make better decisions, move faster and be more confident in
yourself.
Here are some ideas I’ve gleaned over the years.
Read books that challenge your thinking
Read books on subjects that don’t appear related to your
industry. You will soon see how they may relate.
Read books that you enjoy and resonate with. Put down books
that are tough to read or boring. Life is too short and there are
too many books to read.
Listen to Podcasts on commutes, journeys and trips.
Record every single idea that pops in to your head. It’s
amazing how insightful these flashes of ideas and thoughts
can be.
Learn to speed read.
How We Learn 83
Take the time after reading to collate your notes and ideas
about the book. Then store them in a logical way that makes
sense to you. It’s important to know where information is.
But digesting that information and putting it in to action is
knowledge. Knowledge is information in action.
Empty your cup. Sometimes we believe we know everything
there is to know about a subject. We are always wrong when
we believe this. Bruce Lee said to empty your cup so it can be
filled with new knowledge - spot on.
Review your notes and learnings often. I use spaced repetition
to return to my notes 1 month after making them. Do they still
make sense? What else can I learn from them? What further
insights can I glean.
Use 60 day’s proof. Write every note with the view of reading
it again in 60 days. Will it still make sense even when the
context is missing?
Stop learning and studying when you’re trying to create
something. There comes a point when studying must end and
creating must begin. Don’t let studying become the reason
you procrastinate on creating your masterpieces.
Evernote is my tool of choice for learning. It stores everything.
It’s my digital filing cabinet. It’s like a second brain.
Martyn Frank
For me the key to any learning activity is habit. I work to make
times in my day that are perfect opportunities to study. I use
my cycle and train journey to work to listen to podcasts, I read
before I go to bed. I even use the gardening as an opportunity
to listen to a podcast.
How We Learn 84
As you probably guessed my main choice for learning is

podcasts. This is for two reasons, they are normally short (20-
40 mins) and perfect for a commute. They are also much more
informal and discussion based, which I prefer. Other methods
of learning for me are reading books, watching YouTube and
blog posts.
To remain relevant and engaged as a Scrum Master I believe
continuous learning is essential. The key to keeping it in-
teresting is variety, try to listen or read about a wide range
of subjects. You never know when that knowledge will be
helpful.
Raji Bhamidipati
Learning and improving is a big part of my work life. I have
come into scrum mastery from a software testing background.
With that comes an analytical mind and critical reasoning in
everything that I do.
Structure
My learning is often planned and structured. I block book a
couple of hours every week in my calendar and I use this time
for learning activities. Of course I don’t always stick to these,
but they are in place to remind me if need be. I also read a
chapter or two from a book each day before going to bed. I
watch videos or listen to podcasts during my lunch breaks or
whilst running on the treadmill. Trust me, if you are watching
an interesting video running becomes that much easier.
How We Learn 85
Content
I maintain a list of books, blogs, videos and podcasts that
I hope to complete in the next few months. This list keeps
growing as I interact with my colleagues and peers!
At NewVoiceMedia, we also have a book club where we all
read a selected book. We meet every week to discuss the
agreed set of chapters that we have completed. We sometimes
agree on certain things and disagree on others. This leads to
intellectual conversations which are helpful.
Review
I maintain a journal and write entries at the end of each
day. In these entries amongst other things I list learning
that I planned and completed. I also note any unplanned
learning/knowledge that I may have gained during my day.
I review these entries from time to time. They provide an
insight into how I have been progressing. They also show
trends on topics that I have been learning about.
Steven Mackenzie
Train journeys are a great time for me to read without dis-
traction (especially because I have no 3G network connection
on my route!) Going in to work I usually use this time to
read books on an e-reader app. Recently I’ve been looking
for books that offer practical advice to help my teams plan
and to engage business users in the design and prioritization
trade-offs.
How We Learn 86
During the day I often find my colleagues will suggest inter-

esting (but long) blogs or on-line articles. I like to save these
in to the Pocket app (previously called Read-It-Later). These
saved links get cached on my phone, and I can read them on
the trip home. Twitter is also a great place to pick up on trends
and new ideas, and links from there are also easy to share in
to the Pocket app to read when I have time.
At home I’ve discovered wireless headphones, and sometimes
look for excuses to do household chores so that I can listen
to podcasts and conference session recordings on YouTube.
Right now I’m working through the Manager Tools podcasts.
These have me thinking about how I can “talk about results”
more often in my work with teams and individuals. It is in-
teresting to think about re-interpreting the slightly traditional
management and project management advice into an agile
context.
While it is great to read and share the new ideas with my
colleagues at work it is important to me to get out and talk
to people at my local agile user group Agile South Coast¹²
each month. As well as learning and exploring new agile
and Kanban ideas, and trying out workshop formats, it is
great to get the chance to swap war stories and advice with a
sympathetic group of fellow agilists.
¹²http://www.meetup.com/Agile-South-Coast-Southampton-Chapter/
How We Learn 87
Keith O’Sullivan
Learning should be fun.

With all the mediums available to us today there is no excuse
to not be learning, mastering your trade and upping your
game.
Learning is no longer confined to the classroom, the library or
your bedroom. There are no confinements any more. Which
means there are no excuses.
My favourite ways to learn:
Observing.
One of my favourite ways to learn is to observe. As a Scrum
Master I enjoy sitting in on other teams’ ceremonies and
meetings. I find this a great way to learn as not only can
you see other Scrum Masters in action, but you can also
observe the team as well. If you join a new business I would
recommend taking this approach - it’s a great way to onboard.
Podcasts.
Before joining NewVoiceMedia my commute to work and
back took 4 hours, which sucked. BUT I took full advantage
of this and tried to cram in as much learning as possible. I fell
in love with Podcasts and could get through at least 3 shows
a day.
How We Learn 88
Audio books.
I did try reading on the train but found this tiring, so the next
best thing was listening to audio books. I really enjoy audio
books for the same reason I love podcasts, you can listen to
them anywhere.
Books.
I thought I had a good collection of books until I joined
NewVoiceMedia. Since joining I now have a backlog of well
over 20 new titles.
Books for me are for more structured learning and I will
choose books to help me with current issues or projects that I
am currently working on.
I don’t always read a book cover to cover. Depending on the
book, I sometimes jump to relevant chapters to get straight to
the info I need.
We also have a Scrum Master book club and get through
a chapter of a book a week. The chapter is then discussed
amongst the team which I find an invaluable way to learn
in a group setting.
Blogs, Medium and YouTube.

The list in here is endless, you can find articles and videos on
any given subject. I usually use these forms for quick bursts of
learning. 10 mins here, 10 mins there. Sometimes I will focus
on work related topics, other times I will be trying to get my
head around parallel universes and black holes.
How We Learn 89
Take notes.
Whilst listening, reading, watching or observing make sure
you have Evernote (or a note taking tool) open so you can
jot down anything interesting you might come across. Try to
store in a logical manner so you can make sense of the notes
and put them to action at a later date.
Make use of it.

The most important part of learning is to put what you’ve
learned into action. I find the best way to do this is to make
small, measurable changes. Whether it’s for you or your team,
don’t think you can change the world overnight.
Understand what your end goal is, understand where you are
now, introduce small changes to get to your end goal and
continuously check progress.
Acknowledgements
We would like to thank NewVoiceMedia for the time and
encouragement to create this book. Thank you to all of the
people who we have worked with, you helped us to get a
clearer understanding of the ideas that we’ve tried to put
across here.
In particular, this book is much clearer and less distracting to
read after professional technical author Helen Griffith read it
for us. Thank you for kindly and diligently suggesting over
a hundred ways that this work could be better. Weronika
Kedzierska, thank you for teaching us that we can draw and
providing the first line art to get us started.
It has been very welcome to receive helpful feedback from
outside NewVoiceMedia, and to hear that this content is in-
teresting outside of our business. Thank you to everyone who
has taken the time to share their thoughts, and particularly
those who have given us feedback.
Finally, thank you to you for spending your time reading our
book, we hope it has been useful. Perhaps you have time to
leave a review at leanpub.com/beascrummaster¹³?
¹³https://leanpub.com/beascrummaster
90

So You Want To Be A Scrum Master

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

So You Want To Be A Scrum Master

Caricato da

Copyright:

Formati disponibili

So You Want To Be A Scrum

Helen Lisowski, Rob Lambert, Martyn

This version was published on 2016-06-07

This is a Leanpub book. Leanpub empowers authors and

© 2016 Helen Lisowski, Rob Lambert, Martyn Frank, Raji

What to Tell Your Mum When She Asks What You

Scrum Master is a Strange Job Title (but we don’t

How to Tell People What to Do Without Telling

How Do You Become an Expert in a Room Full of

What Has a Scrum Master Ever Done for Us? . . . . 20

You’re Not the Admin Lacky . . . . . . . . . . . . . . 24

Being Effective and Liked . . . . . . . . . . . . . . . 27

New Team Members Adopt the Same Behaviours as

This is the Team to Get it Done . . . . . . . . . . . . 33

Using Small Steps When Big Changes Might Be

Why is Coffee Important? . . . . . . . . . . . . . . . 41

Being Flat Out Busy is Not Effective Agile . . . . . . 44

The Framework Curse . . . . . . . . . . . . . . . . . 48

The Kind of Person Who Knew Too Much . . . . . . 51

No Process is Perfect, but it Doesn’t Mean it’s Crap . 53

Reduce Failure Demand . . . . . . . . . . . . . . . . . 59

Agile Consultants Who Don’t Know What it Means

What Would a Customer Say if You Shipped it Now? 72

Whilst Doing This, You’re Not Doing That . . . . . . 74

Scrum Master - What Happens Next? . . . . . . . . . 77

build out their knowledge.

Why is this question even

Ladies and Gentlemen, may we

It is also worth saying that there are some things we really

Help each member of the team to be the best

Help each team member contribute their best

The Scrum Master here is the oil in these gears

Are the agile expert for the team.

Coach the team in process, practices and any-

Spot waste within the current processes.

Shine lights into the darker corners where others

Help people to do the ‘right’ thing rather than

Maximise the time a team member spends doing

Help the team to build great habits, both as

What our ‘mums’ really said

Similar to a project manager, but more hippy.

When quietly asked by my dad if she knew what a Scrum

You talk to people and help them do their best

Listen patiently to the team and delegate as ap-

You all just stand around talking to each other

A project Team Lead?

[Doing what?] Put together time lines and give

*other family members are available and can be substituted

Jack of all trades, master of what?

Too obscure - what do the words

Too specific - do we only do

Scrum Master: the role within a Scrum Team

When you take a new job as a Scrum Master it can be unclear

Why do we use it then?

even if not the most accurate. However, even in this case we

• Scrum Master (433) Widely understood to be generic,

Being a Scrum Master can sometimes come with the miscon-

version of themselves. To be the agile expert for the team.

Get the team excited about the

Every person is different

some of the more common personalities.

Let the team fail

Use the people at your disposal