Introduction………………………………………………………………………………………………………………………………………………..

… 4
The Scrum Master……………………………………………………………………………………………………………………………………..…. 5

First Steps
Starting Scrum……………………………………………………………………………………………………………………………………..……….. 6
Complexity ………………………………………………………………………………………………………………………………………………..…. 7
Terminology………………………………………………………………………………………………………………………………………………….. 8
The Importance of Empiricism.……………………………………………………………………………………………………………………… 9
Transparency, Inspection and Adaptation……..……………………………………………………………………………………………… 10
Leaders who Serve ……………………………………………………………………………………………………………………………………….. 11
Successful Teams……………………………………………………………………..…………………………………………………………………… 12

Teams
The Product Owner ……………………………………………………………………………………………………………………………………… 13
The Developers ……………………………………………………………………………………………………………………………………………. 14
Ways of Working…………………………………………………………………………………………………………………………………………... 15
Vision and Validation.……………………………………………………………………………………………………………………………………. 16
Getting Stuff Done.……………………………………………………………………………………………………………………………………….. 17
Impediments…………………………………………………………………………………………………………………………………………………. 18
Technical Debt.……………………………………………………………………………………………………………………………………………… 19
Building Quality in.………………………………………………………………………………………………………………………………………… 20
Metrics………………...………………………………………………………………………………………………………………………………………. 21
Product Development

Progress is Rarely Linear………………………………………………………………………………………………………………………………. 22

Sprints ………………………………………………………………………………………………………………………………………………………….. 23
Choosing a Sprint Length……………………………………………………………………………………………………………………………… 24
The Scrum Artifacts………………………….…………………………………………………………………………………………………………... 25
The Product Backlog….…………………………………………………………………………………………………………………………………. 26
Sprint Planning …………………………………………………………………………………………………………………………………………….. 27
Setting Goals ………………………………………………………………………………………………………………………………………………… 28
The Sprint Backlog………………………………………………………………………………………………………………………………………… 29
The Daily Scrum ……………………………………………………………………………………………………………………………………………. 30
Producing an Increment…………….…………………………………………………………………………………………………………………. 31
Effective Sprint Reviews ………………………………………………………………………………………………………………………………. 32
Effective Sprint Retrospectives …………………………………….……………………………………………………………………………… 33
Product Backlog Refinement ……………….………………………………………………………………………………………………………. 34
Complimentary Practices………………………………………………………………………………………………………………………………. 35
Scaling Scrum………………………………………………………………………………………………………………………………………………… 36
Elevator Pitch ………………………………………………………………………………………………………………………………………………. 37
Next Steps

Mindset ……………………………………………………………………………………………………………………………………………………….. 38
Building Trust ……………………………………………………………………………………………………………………………………………….. 39
Fail Fast, Learn Fast………………………………………………………………………………………………………………………………………. 40
Organisational Change …………………………………………………………………………………………………………………………………. 41
Quotes from Jeff and Ken…………………………………………………………………………………….........................................… 42
About me……………….……………………………………..……………………………………………………………………………………………… 43
“ Teamwork is the ultimate competitive
advantage. Not finance, not strategy, not
technology… teamwork. Both because it
is so powerful and so rare.

Patrick Lencioni
Starting your journey as a new Scrum Master can be overwhelming if you don’t have
someone to mentor you. Of course you’ll be expected to have a deep understanding of
Scrum Theory, how Scrum works in the real world and an awareness of all things Agile. But
to be successful at various times you’ll also need to be a servant leader, facilitator, problem
solver, mentor, teacher, manager, conflict resolver, a change agent and a leader who serves
the organisation as well as a coach for the team.

If all of that sounds like a big ask that’s because it is! No-one said it was going to be easy.

But there’s an additional challenge we often forget about and that’s when a relatively new
Scrum Master leaves their first team and starts all over again with another team. Because
this is when we are confronted with all of our misconceptions, shortcomings and perhaps
even our own complacency. Theory that was previously taken for granted is questioned.
Events that were enjoyable are now confrontational. And practices that proved to be
successful now fail or, even worse, are rejected out of hand. All of the excitement that
comes with starting a new role can quickly dissipate or even turn to frustration.

Don’t panic!

This guide is everything that I wish I’d known ten years ago… or at least this is an overview
of some of the things I wish I’d known. Whether you’re a new to Scrum or just starting with
a new team, this guide is written for you. There’s no blueprint for success with Scrum. But I
can fill in some of the blanks, elaborate on some of the theory and make some suggestions
so that maybe you can avoid some of the basic mistakes that I’ve made over the years.

You’ll then be free to go on and make your own, totally new mistakes! Enjoy the journey!

Duncan Maddox, Scrum.org Professional Scrum Trainer

4
Being “a Scrum Master” isn’t a qualification or a seniority or even
necessarily a full time job, it’s an accountability within a team. Scrum
Masters don’t need to pass an exam although enhancing your
understanding of Scrum with a training course might be helpful and
certifications don’t harm your chances of finding paid employment!

IMHO there are only 3 basic requirements to qualify as a Scrum Master…

1. You’ve read The Scrum Guide

2. You’re familiar with “the Agile Manifesto”

3. Someone wants you as a Scrum Master

If you meet these requirements, you’re a Scrum Master. Of course you

might not be a *great* Scrum Master yet, but you’re on your way.

Everyone finds their own path but you could start with the following…

• Humble, empathetic and always interested in learning more

• An expert on the Scrum Framework and other Agile approaches
• A good communicator and an even better listener
• Organised, proactive and decisive… because there’s always a lot to do!
• An excellent facilitator and a creative problem solver
• Patient but also persistent because change takes time

5
Many organisations spend too much time gathering requirements, putting
intricate designs together and trying to formulate a detailed plan before they start
building the product. But these plans and designs are based on unvalidated
assumptions and the only way to validate assumptions is by building something.

The lesson is simple. Stop making excuses. Start Sprinting now.

But what exactly do you need before you start your first Sprint?
• A Product Goal, i.e. a product you want to build or value you want to deliver
• Work in your Product Backlog for your first Sprint
• A Team

That’s it.

You’ll need to choose a Sprint length and define a Definition of Done.

You’ll need to identify and engage key stakeholders.

You’ll very probably need to do a lot more planning and design along the way.

But you can do these things during your first Sprint and in subsequent Sprints and
they shouldn’t stop you from starting. Every day that you wait is a missed
opportunity. You have assumptions about what your team can build and how the
technology will work and what it will cost and what your customers want. You
could be validating those assumptions.

Assemble a team with the skills to deliver, see what they can get done and then
get your customers using it as quickly as makes sense.
6
Scrum isn’t just for software, it’s for developing any complex product or
service where you want to get stuff done and deliver value and respond
to change.

Complex products are built by teams of people with lots of different

skillsets where there are known unknowns, unknown unknowns,
customers who don’t really know what they want or don’t actually want
what they say they want, technology that the team hasn’t used before as
well as there being changes and other uncertainties in the outside world
that may effect the end product.

And these multi-disciplinary teams that we need to build complex

products are in themselves inherently complex. No two teams are the
same. What works with one team may very well not work with another.

The Scrum Framework is designed to help these teams make better

decisions about what to do and how to do it.

But Scrum isn’t a complete methodology or a blueprint for success

because there are no simple solutions for really complex problems. But it
is a container for your processes, a minimal set of accountabilities, events
and artifacts that you can use to improve your plans and processes and
teamwork and ways of working as you wrestle with complexity.

You don’t have to adopt Scrum in it’s entirety… but if you don’t then
you’re not actually doing Scrum and you very possibly won’t get the
outcome that you were hoping for.

7
If we’re honest we all have little things that irritate or trigger us. Mine is people
using the word “ceremony” rather than “event” because the word ceremony
makes me think of people dressing up in robes going through pointless rituals
that no-one really understands because the original purpose has been long since
forgotten. And that’s not what a Scrum event is. A Scrum event is a timeboxed
meeting with specific attendees designed to have a specific outcome and the
terminology was chosen specifically to distinguish events from meetings which
are often seen as wasteful and pointless.

Scrum has lots of very specific terminology. Events not ceremonies. Daily Scrum
not stand-up. The Sprint Review not the demo or show and tell. Teams not
squads. Scrum not SCRUM. And so on.

You can argue that using the right terminology is both vital and at the same time
trivial, in that if the organisation is doing the right thing then it really doesn’t
matter what labels they use but if they haven’t invested the time and effort in
learning the correct terminology then it’s unlikely they’ve invested the time and
effort in understanding the underlying theory. If they won’t change the words
they use then how likely is that they’ll change the way they work? Having a
common language and understanding is useful and removes ambiguity.

Having said that you’ll probably want to make judgement call when you start with
a new team. If you constantly correct their use of language you might create a
first impression as someone who nit-picks over unimportant details. Take your
time and adopt a light touch. I find that people are open to updating their
vocabulary if you don’t jump all over them every time they misspeak.

8
Building a complex product, you just can’t plan it all out perfectly and if
you try your initial detailed plans will almost certainly be very wrong.

That isn’t to say that Scrum Teams don’t plan. Scrum Teams spend a lot of
time planning. But they embrace change and focus their detailed planning
on what’s probably going to happen in the next few Sprints. And great
Scrum Teams are totally transparent about their actual progress against
those plans and where they’ve failed to make progress.

Working with an empirical approach you will need to ensure there is

genuine transparency else all of your decisions will be based on bad or
incomplete information. You’ll need to encourage the team to be open
and honest about what they have done, what’s not done and what
problems they encountered along the way.

The culture of the organisation is a huge factor here. The team need to
feel they can talk openly without fear of blame or reprisals. They should
adopt a mindset there is no good or bad news… there is just news.

You won’t always be able to provoke the changes that need to be made.

But you can always, always raise transparency and ensure that decision
makers have the information they need to make any necessary changes.

9
• Are the team comfortable working in an Agile way, breaking work down and
delivering it in an incremental and iterative way?
• Do the team regularly update the Product Backlog and Sprint Backlog?
• Are they able to produce a done, useable, valuable increment every Sprint?
• Do the team trust one another and are they working towards common goals?
• Is there a blame culture in the organisation?
• Are the team trusted, empowered and allowed to (sometimes) fail?
• Are the team nervous about speaking up in front of senior stakeholders?
• Is there a fear of conflict?

• Does the organisation understand that the plan for the Sprint isn’t set in stone
and updating timelines and scope for product delivery is not only normal but
also desirable?
• Does the organisation want to deliver on time and scope or do they want to
create the best product they possibly can?
• Are the team able to change their ways of working?
• Are stakeholders actively involved and participating in Sprint Reviews?
• Are management open to change and that that change might involve them?
• Do the team create their own estimates or are estimates imposed on them?
• Are the team trusted to come up with their own solutions?
• Once a plan has been made, is it difficult to change that plan?
• Are estimates taken as commitments?

10
Scrum Masters are leaders. So you might want to
give some thought as to exactly what your personal
leadership style is.

You could start with a new team thinking that you

have all the answers with the intention of shaping
them in your image. You might think that whatever
worked with your previous team will work with your
new team. After all, people are all the same aren’t
they!? (spoiler, no they aren’t).

Many Scrum Masters start off with a new team

wanting to change thirty things by Thursday before
they even understand what challenges the team has.

This approach is rarely successful..

Instead you could start with humility, empathy and

curiosity. Ask questions. Listen to the answers. Share
your experience. Talk about how you can help the
team but also where you need help.

Try to find out the teams goals, their strengths and

weaknesses and what is holding them back.

And then ask the team how they would like you to
help.

11
Scrum isn’t meant to be easy. It’s designed to provoke change and change pushes people outside their comfort zones. If you are
starting with a new team you’ll want to observe whether they are “living and breathing” the Scrum Values. It’s all too easy for a
team to go through the motions, attend all the events, update the artifacts and then say “Scrum doesn’t work here” whereas
the reality is that maybe they never had the courage, focus, commitment, respect or openness to make it work.

Courage
Do they have the courage to push back against unrealistic demands, to stand up and share their concerns, to challenge one
another, to hold each other accountable, to ask difficult questions and hold their hands up when they’ve made a mistake?

Focus
Are they focussed on the Sprint Goal and able to stay focussed when distractions inevitably arise?

Commitment
Are they committed to the team’s goals or their own personal goals? Are they willing to collaborate and find solutions when
things go wrong or do they throw their hands in the air and give up? Are they willing to try something else? Are they willing to
volunteer for tasks they don’t particularly enjoy or that aren’t in their core skillset if it’s in the best interests of the team?

Respect
Do they treat their team-members and co-workers with respect? Do they value the rest of the team and treat them as equals?
Do they listen to other opinions without constantly interrupting? Do they turn up to meetings on time and are they present
during the meetings?

Openness
Finally, are they open to alternative solutions or to asking people outside the team for their advice? Do they have a fixed
mindset? Are they insular and part of a clique or are they willing to embrace alternative ideas and suggestions?

12
Every Scrum Team needs a Product Owner. Someone who has a vision for the product and is able to translate that vision into an
ordered Product Backlog of features, fixes, enhancements and bugs. But what makes a great Product Owner?

The Product Owner is part of the Scrum Team. They should have time to attend Sprint Planning, the Sprint Review and the
Sprint Retrospective but also collaborate with the team and answer questions and make decisions as required during the Sprint.
If they can’t make time for this then what message is that sending about the importance of the product?

The Product Owner is one person. Not a team. Not a proxy. This doesn’t mean that the Product Owner can’t delegate tasks or
ask people to do the work. It just means that ultimately they make the final decision and they are accountable for those
decisions. If you don’t have a single person as your Product Owner OR your Product Owner doesn’t have enough “free time” to
collaborate with the team, then you have a problem!

Because a Product Owner isn’t just someone who maintains the Product Backlog, they are a value maximiser. They should have
a strong understanding of the organisation, the marketplace and be able to articulate a powerful vision for the product the
team are building. Their decisions decide how much value the team delivers and so they need to have a certain amount of
authority in the organisation because their decisions need to be respected by all of the key stakeholders who will very probably
have contrary opinions on what “maximum value” means.

Does your Product Owner have a powerful vision for the product they want? Are they familiar with the organisation and what
the customers want? Are they able to translate that vision into a backlog? Can they collaborate with the rest of the team?

And if not, ask yourself what can you do to coach them and help them grow into the role?

13
The Developers (formally referred to as the Development Team) are the people responsible for building the product, whatever it
is. Developers doesn’t mean “coders”… it means Product Developers. The team should have all of the skills required so that
they can deliver value, working product, without having to rely on people outside the team. In a technical environment, that
might mean coders, testers, analysts, web developers, ops and architects all working together in one team. If the team
members are used to working in a more layered way with teams of other people with the same skillset this new way of working
can be disruptive and you should expect some amount of conflict whilst the team adjust.

As such, if we’re expecting the team to change their working practices then it might help if they understand the benefits. You
can’t “do” Scrum to a team. As Scrum Master you’ll want to explain basic Scrum Theory, the advantages and the challenges of
Product Development with Scrum as well as the purpose of each of the events and artifacts to avoid the team defaulting to
mechanical or “Zombie” Scrum where they end up going through the motions without benefit or purpose.

Don’t underestimate how invasive a change Scrum is. It’s not just a fifteen minute meeting every day. It’s a completely different
way of working and if your team are unhappy working within the boundaries of the Scrum framework you’ll need to invest
some time and effort helping them understand that the benefits are worth the effort.

Scrum Teams are self-managing and cross-functional for good reasons. Multi-disciplinary teams involve too many people with
too many skills for one person to be able to craft the best solution. So the solution has to come from the experts, the team.
They have to be empowered and trusted. And they need all the skills required to get the work done to avoid information silos
and hand-offs and loss of information.

Working with a new team you’ll want to ensure that they are trusted and empowered to come up with their own solutions,
their own estimates and allowed to do the work as they see fit within the standards of the organisation. The flip side of this is
that they should understand that they are collectively accountable for building a quality product to the best of their ability.

With great power comes great responsibility!

14
Starting with a new team you’ll probably very quickly make judgements about
how they gel together and whether there are any obvious dysfunctions.

Are they able to discuss different solutions and approaches without everything
turning into a heated argument? Do their skills and personalities compliment one
another or do they clash? Do one or two people dominate the group? Are some
team members quiet and not contributing? Are they an effective team?

Of course your judgements might not always be right so don’t be too quick to
jump in and feel you have to change things!

Great teams have an identity and find their own way of working towards their
common goals. They find ways of problem solving and communicating and
working together that work for them and because every team is different their
ways of working will be their own.

If the team is struggling with basic conflict and expectations, it might be helpful to
help them put together some kind of working agreement. What are their core
working hours? When do they need to be available. What time is the Daily Scrum
and does everyone need to attend? If they are a distributed team then what are
their agreements for video meetings? How do they want their discussions to be
facilitated? How would they like to talk to one another?

Your team might have already informally worked these out. They might have no
need to write them down. Or they might not even have considered them. If you
see lots of trivial wasteful conflict you might consider asking the team to put
together a Working Agreement or Ways of Working. But if it’s dictated by you it’s
unlikely to stick. It has to be something they own.
15
When starting with a new team, it can be very tempting to focus on the team’s practices and any obvious “Scrum Fouls”. But if the
team don’t really understand the product they’re trying to create then they’re unlikely to build the best version of the product that
they can. Not only does a strong vision help them collaborate with the Product Owner, it’s also often very motivational for the team
to understand exactly what they’re trying to achieve from the business’s perspective.

A lot of organisations have this vision but don’t share it with the team. You and the team should have a clear understanding of the
vision for the product and if you don’t you’ll want the Product Owner to spend the time explaining it. If the Product Owner doesn’t
have a vision then you’ll want to help the Product Owner create that vision.

A good vision describes the desired future state of the product but it’s more than just a list of features and deliverables. It’s
inspirational, challenging and it encapsulates what problems the product solves for customers and what makes the product unique.
It motivates and guides the team when they uncover complexity and when they have to make trade-offs and difficult choices.

A powerful vision can also help eliminate the waste of the team working on the wrong thing, something that is often overlooked.

However powerful your vision is, until it’s realised it’s based on assumptions about what you can build and what your customers
actually want and need. So a good Product Owner looks to validate their assumptions by pushing the product to market as soon
and as often as is useful to understand what the team can get done and what their customers actually want.

Just because you’re working in Sprints doesn’t mean that you’re doing Scrum. Are you using the Sprint Review as a demo or are you
using it as an opportunity to collaborate with your key stakeholders and adjust your plan for the product?

If not, you’ll need to ask some tough questions. Or to put it another way, how much risk are you comfortable with? What happens
if you’re building something that doesn’t work or that isn’t cost effective or that no-one wants?

16
Scrum has a Definition of Done because without an explicit definition of
Done everyone implicitly has their own definition of done.

What does that mean?

If someone from the business asks me to write a database report I might

say it will take until tomorrow to get that done. And when they come
back the next day I’ve got something working on my computer which
means “done” to me. But the person from the business expects “done” to
mean tested and deployed and ready to use on the live system. And that
might take me days or weeks or months to get done by their definition!

Scrum Teams avoid this ambiguity by clearly stating what “done” means.

Many teams that think they are doing Scrum aren’t getting work done.
They are getting tasks done not features. Or they are coding but not
testing every Sprint. Or they cut corners to get things done knowing
rework will be needed. And when the users ask to use the latest version
of the product, suddenly it becomes apparent that it’s not “done” at all!

Ensure your team clearly states their Definition of Done and share it with
the business. It doesn’t have to be perfect but it should reflect what the
team are capable of. The team should discuss the possibility of improving
their Definition of Done regularly in the Sprint Retrospective, particularly
when a Sprint highlights deficiencies in their definition.

Consider this experiment. Ask, if we release everything tomorrow what

would happen? If you see panic then you might have a problem.
17
A lot of Scrum Teams talk about “blockers” when they’re talking about what’s
stopping them getting work done but The Scrum Guide refers to “impediments”,
meaning anything that was blocking or slowing the team down.

As Scrum Master you are ultimately responsible for causing the removal of
impediments, whether you are empowered to remove them directly or not.
So when you join a new team you’ll absolutely want to keep an eye on what’s
slowing the team down whether it’s internal to the team, external to the team,
technical, teamwork or process related.

If the team don’t have the resources or skills they need to get their work done,
that’s an impediment. If they are constantly being interrupted by stakeholders,
that’s an impediment. If they can’t focus on the Sprint Goal because they have
too many unproductive meetings to go to, those meetings just might be
impediments. If they are wasting time doing pointless documentation that no-one
reads to meet outdated organisational standards that might be an impediment.

And if you can teach the team to solve their own problems, even better.
Remember, every time you step in and solve the team’s problems for them you’re
denying them the opportunity to learn how to do something for themselves.

People are not impediments but their behaviours and their impact on the team
may very well be. As Scrum Master you normally don’t and probably shouldn’t
have the authority to hire and fire people but you should help the team if some
team members behaviour is unhelpful, dysfunctional or toxic.

18
If your team is just starting off building a new product then you probably don’t have to worry too much about the quality of what’s
already been done. But if you’re joining a team which has been working for a while they might already have incurred considerable
technical debt and it’s your responsibility to ensure they raise transparency on this and that the Product Owner understands the
importance of paying this technical debt back.

If your team has already “done” something but that done product is poorly made, unmaintainable, unstable, not performant or
not properly documented then that can be referred to as “technical debt” because your stakeholders believe something is done
but there’s “debt” that sooner or later the team need to “repay” and spend time fixing without delivering any additional value for
the stakeholders.

Scrum teams work in an iterative and incremental way. This means they deliver products one piece at a time, so they will typically
add and amend and modify existing code (or product) more than traditional teams. Because of this their technical practices need
to be at least as good as traditional teams if not better to enable this Agility. We can’t write some code and consider it done just
because it works right now. It needs to be maintainable by everyone on the team and easily modifiable without breaking.

As Scrum Master you are responsible for helping the team raise transparency on existing technical debt. Ensure the Developers
understand the importance of building quality in and not cutting corners. Once you’ve identified technical debt, add it to the
Product Backlog just like any other work and ensure the Product Owner understands the importance of prioritising it
appropriately. And consider enhancing the Definition of Done to prevent the team adding more technical debt!

With a mature product this process might take months or even years to complete but this isn’t a reason not to do it. Be realistic
but persistent because only once you have paid this back will your team be in a position to be truly Agile.

19
If your team feel under pressure to deliver lots of work every Sprint then they
might end up rushing, cutting corners and building a poor quality product.

This is an anti-pattern and something that you as Scrum Master want to help the
team avoid.

Studies show that it is exponentially more expensive to fix defects and bugs and
problems after the fact. For example, it might take ten times as long to fix a bug
once it’s been deployed to a test environment as opposed to fixing it during
coding. It might take a hundred times as long to fix a bug once it’s been released
to a production system compared to finding that bug before it’s been released.

The message should be clear. Build. Quality. In.

This might mean that the team appear to go slower. That’s fine because you are
then getting a true understanding of what the team can do to acceptable quality
standards. Cutting corners and lowering quality to “get stuff done” actually makes
the team slower in the long term so should be avoided unless there is a deadline
which the team need to hit and deliberately choose to incur that technical debt.

Scrum Teams maintain quality with the Definition of Done. If your product needs
to be documented to certain standards add that to the Definition of Done. If the
team thinks a peer review will help quality, add that to the Definition of Done. If
poor quality product makes it into the “done” increment ensure this is discussed
(possibly at the next Sprint Retrospective) and ask the team what they can do to
prevent this happening again in the future.
20 20
If there’s one thing that every organisation doing Scrum is obsessed with it’s velocity. Which is odd because they really shouldn’t
be. And for what it’s worth, it’s not even mentioned in The Scrum Guide… not even once.

Velocity is a measure of the amount of Product Backlog turned into increment, often based on the team’s estimates i.e. the number
of story points or person days or features. Velocity is seen as a measure of the team’s productivity and management often think
that their job is to drive this velocity up or hold the team to account when velocity doesn’t meet targets.

This behaviour isn’t useful and is more often actually counter productive.

For starters all of the measures above are based on the team’s estimates. So the team could increase their estimates to drive the
velocity up without doing any more work. Alternatively there are lots of ways the team could go faster. They could cut corners. They
could reduce all that wasted time testing. They could rush things out. Or not document their work. Or they could only pick easy
work and ignore complex challenges.

None of these outcomes are desirable. So as Scrum Masters we need to work with management to help them see that velocity is
not a stick to beat the team with. Instead of telling the team to go faster we should be asking the team what’s slowing them down.

And also, not focussing on velocity because it’s really not that important.

So what should be we be focussing on instead of velocity or productivity???

Value, of course! Revenue. Return on Investment. Net Promoter Score. Customer Satisfaction. Cycle time. Lead Time. Quality.

If you start with an organisation which is driving their teams by velocity one of your first tasks is going to be helping them start to
use a better set of metrics. But always remember that great metrics are not the target, the target is a great product!

21
If you expect your team to deliver work smoothly and predictably you are
going to be disappointed because complex work isn’t perfectly
predictable and easy. If it were we wouldn’t need Scrum.

Managers will often ask the Scrum Master to make the team’s velocity
“more predictable”. And if a team gets less done than estimated in Sprint
Planning they demand to know why and ensure it never happens again.

This attitude is not productive and as a Scrum Master you’ll want to help
stakeholders and management understand the risks inherent in complex
work.

Sometimes the team will get everything done that they forecast.
Sometimes they won’t. This doesn’t mean that the team are lazy or stupid
or incompetent. It’s the nature of complex work. Complex product
development involves risk and uncertainty and discovery.

Scrum Teams deal with this by prioritising risky, uncertain work and
getting it done or discovering the challenges. They are transparent about
their progress and problems so that stakeholders can make informed
decisions based on the actual state of the product not the desired state of
the product.

It’s not unusual for a team which is new to Scrum to fail spectacularly in
their first Sprint as they massively over-estimate what they can get done.

The greatest teacher, failure is.

22
Love them or hate them, Scrum is based around delivering done working product
within Sprints.

Essentially Sprints are just a timebox, a fixed amount of time for the team to
deliver something of value.

For me this is one of the most compelling reasons for using Scrum. By asking the
team to deliver useable product in a fixed length Sprint not only do we deliver
value early but we also find out what the team can do in a fixed amount of time.

Not what they think they can get done.

Not what their manager says they should get done.

What they actually can get done.

And that helps us to make much better forecasts (or estimates or guesses) about
what the team will be able to get done going forwards. And if we use this
information we can then adjust our plans and come up with a much better
understanding of when things will probably be ready.

Once you’ve started a Sprint, don’t change the Sprint length. If the team finish
early they can bring in more work or work on process improvements. If they have
over-committed they can collaborate with the Product Owner to adjust scope and
agree what they actually can deliver. You aren’t tied to that Sprint length forever
so encourage experimentation until you find a Sprint that works for the team.

23
Everyone knows that two weeks is the standard Sprint length… except that it isn’t.
There’s certainly nothing in The Scrum Guide specifying what Sprint length is
“best” because the optimal sprint length is going to depend on your team and the
product and lots of other factors.

So how do you choose a Sprint length?

Start off by asking the team how long it takes them to get something of value
done.

You’ll want to factor in the complexity of the product, how often your stakeholders
are available to attend the Sprint Review, how dynamic the market is and how
often priorities change and how often the Product Owner wants to respond to
change and the amount of risk involved in what you are building.

You’ll probably do all that and settle on two weeks and maybe that’s fine. My
preference is for shorter Sprints. Teams often think that shorter Sprints involve
more meetings, more overhead, less time working. I’d disagree. Sprint Planning
and Reviews can be proportionally shorter and forming a Sprint Goal simpler. In
addition shorter Sprints give the team lots of opportunities to become familiar
with the cadence of delivering and understand how the Scrum events work.

As with everything in Scrum, try it and see what works. Once you’ve started a
Sprint don’t finish early or extend the Sprint length as you won’t learn what the
team can get done in that time. Settling on a consistent Sprint length is
encouraged as it allows the team to develop of rhythm of getting stuff done.

24
The Scrum artifacts are all designed to assist the team in raising transparency.

The Product Backlog essentially contains the plan to achieve the current Product Goal, which is set by the Product Owner. So
check that the Product Owner has identified a Product Goal and is using it to guide what’s put into the Product Backlog.

Every Sprint should have an over-arching Sprint Goal that represents the value that the Product Owner wants from the Sprint.
The Developers should own and update Sprint Backlog as their plan for achieving the Sprint Goal and we should expect it to
change as the team discover more about the work they are doing. You’ll want to ensure they are not treating their forecast
from Sprint Planning as a commitment. Complex work is inherently risky and unpredictable so if the team discover that work is
easier or more complex than anticipated they should adjust their plan… even if that means adding or removing items from the
Sprint!

At the end of every Sprint the Scrum Team and stakeholders have an opportunity to examine what has been done up until this
point, discuss anything else relevant such as the current release schedule and what’s happening in the outside world and then
update the plan for the product, i.e. the Product Backlog. Note: this isn’t the only time that stakeholders have an input in
changing the plan but it’s a scheduled opportunity at the end of every Sprint. If your team aren’t inviting stakeholders to the
Sprint Review or stakeholders aren’t turning up then this is a risk you’ll probably want to address.

The Scrum artifacts are only useful if they reflect the true state of the product.

In other words, the team and stakeholders can only make good decisions if the Scrum Team are open and honest and
transparent about what’s done and what’s not done. On starting with a new team as Scrum Master you’re first focus will often
be on raising this transparency and helping the organisation understand the implications of making decisions based on
incomplete or bad information.

25
The Product Backlog is the plan to achieve the Product Goal, the single
source of the truth for all features, fixtures, enhancements and bug fixes.

If you don’t have a Product Goal then your Product Owner needs to
create one. This can be tactical or strategic and might be achievable in
two months or two years but the team should be working towards
something tangible.

Don’t let perfect be the enemy of good. Don’t expect to have a perfect,
finished Product Backlog before the team start their first Sprint. The
Product Backlog isn’t ever finished until the product is finished, i.e. the
team are no longer working on the product. Expect the plan for the
product to change as the team learn what they are capable of doing and
as stakeholders see useable product and give feedback and things change.

Scrum Teams embrace change. The alternative is ignoring discovery and

learning and then choosing to build an inferior product just because that’s
what was originally planned. And that makes no sense.

Many Product Owner struggle ordering the Product Backlog, they struggle
picking one thing as the top priority and putting it at the top of the
backlog but if everything is number one priority then nothing is.

If the Product Owner is unsure how to order the Product Backlog then
help them order it by value, risk, return on investment, dependencies and
whatever else is important to them!!!

26
Sprint Planning is an opportunity for the Scrum Team to establish the value that they will deliver in the Sprint, what Product
Backlog Items they will get done to deliver that value and start to put a plan together for getting it done.

When starting with a new team try to help them craft a goal which is valuable, achievable and flexible. The objective should
come from the Product Owner but the feasibility comes from the Developers so this requires some collaboration. If you have a
very senior Product Owner who is used to getting their own way you may need to coach them on the importance of
collaboration. They should understand that they won’t get the best results by dictating what the team should do.

A successful outcome from Sprint Planning would be a Sprint Goal, some well understood Product Backlog Items to achieve that
goal and enough of a plan for getting it done that the team are confident they understand what needs to be done.

The plan doesn’t need to be perfect because it will never be perfect or even complete. It’s fine that the plan is emergent, i.e.
that the team inspects and adapts and completes the plan as they go… if that wasn’t necessary then there would be no point in
having the Daily Scrum!

Sprint Planning is for the entire Scrum Team.

Teams often find Sprint Planning boring, especially if their Sprints are on the longer side, they may spend a whole day in
planning. This doesn’t need to be a meeting with everyone trapped in a room. It’s an event.

Some Product Owners may see the “technical team” as a barrier to some perfect version of the product that only they can
envisage. They probably don’t appreciate the complexities of the technical work. If this is the case it can be useful to get the
Developers to share the technical details of what’s involved in getting something done.

Planning Poker and other techniques can help during Sprint Planning. But remember that the benefit of such practices isn’t
really the estimate, it’s the discussion that it provokes and the common understanding that emerges from that.
27
If you want your team to feel like they’re on a hamster wheel, constantly running without getting anywhere with one Sprint
blurring into the next then don’t bother to set goals and ask them to just keep churning out work. If however you want them to
be motivated and involved in the end product then Goals are an excellent way to encourage engagement.

The Product Goal can be tactical or strategic and should be defined by the Product Owner. It might be something that the team
can achieve in two months or two years but it should definitely be a goal, i.e. something the team can work towards and know
when they have achieved it. That Product Goal should then guide what goes into the Product Backlog. If a piece of work isn’t
contributing towards the Product Goal then feel free to ask why it is in the Product Backlog (there may be a good reason!).

Every Sprint needs a Sprint Goal which is valuable, achievable and flexible.

The Sprint Goal represents the value that the Product Owner wants from the Sprint. But the Developers, the people doing the
work, should be confident that the goal they’ve selected is achievable. And it needs to be flexible or negotiable in some way so
that it guides the team but also is more than just a list of features that the Product Owner wants done.

Sprint Goal Case Study

Imagine you are working on a banking portal. The Product Owner wants customers to be able to check their
account balances. So the team bring in Product Backlog Items for the different account types (Current, Savings,
Mortgages). But halfway through the Sprint they discover that the Mortgage account calculations are much
more complex than anticipated. Fortunately the Sprint Goal they agreed was “Allow some customers to check
account balances”. This was valuable to the Product Owner, achievable in that it allowed for discovery and
flexible in that it could be achieved in different ways. The team finish the Sprint with Current and Savings
customers able to check balances so although they didn’t get everything done that they forecast they still
accomplished the Sprint Goal.
28
The Sprint Backlog is the plan for the Sprint, and once Sprint Planning has
finished it’s owned and updated by the Developers, i.e. the people doing
the work. They are the people accountable for getting this done so it only
makes sense that they update their plan.

As Scrum Master when you’re starting with a new team it can be

tempting to create a role for yourself managing the Sprint Backlog. But
this fosters a dependency which isn’t useful when there are many, many
other things for a new Scrum Master to be doing.

Choosing a Sprint Goal can be difficult but a goal which defines what the
Product Owner really wants from the Sprint helps bind the team together
working towards a shared objective. If you don’t have goals then you
might notice you also don’t have a team… you just have a lot of
individuals working together.

The Sprint Backlog should be a real time picture of the team’s plan for the
Sprint. Technical people often focus on the individual problem they are
trying to solve at that moment so you should ensure that the team make
time for the Daily Scrum because that’s 15 minutes (max!) when they
have permission not to be coding or building but instead checking in with
the team that they are building the right thing in the right way.

You’ll want observe the Sprint Backlog to see whether the team have a
good flow throughout the Sprint or for example, do they leave all the
testing until the end of the Sprint and risk falling at the final hurdle.

29
I’d argue that no other Scrum event is as misunderstood as the Daily Scrum. Certainly it seems to be the part that draws the
most negative attention. So let’s start by clearing up some common misunderstandings.

The Daily Scrum is not a status reporting meeting or a problem solving meeting.

It’s not about micro-managing the team.

You don’t have to use “the three questions” and you don’t need to stand up.

So, what is the Daily Scrum all about?

Every event in Scrum is an opportunity to inspect and adapt and the Daily Scrum is no different. It’s the Developers opportunity
to inspect their progress towards the Sprint Goal and adapt their plan for the Sprint. They should come out of the meeting with
a common understanding of what impediments are slowing them down and what they are doing for the next 24 hours.

A surprising number of Scrum Masters think that they need to facilitate this event. If you’re working with a team which is new
to Scrum then that’s probably a good use of your time as Scrum Master. But this is an event by the Developers for the
Developers. As Scrum Master, you don’t need to run this meeting or facilitate this meeting. You don’t even need to be there.
You just need to make sure that the team are having it and keeping to the timebox!

An effective Daily Scrum should assist the team achieving their Sprint Goal. The flipside is with an ineffective Daily Scrum you’ll
often get to the end of the Sprint only to suddenly discover that the team aren’t going to achieve the Sprint Goal.

What format is most effective for the Daily Scrum? Well, whatever works for the team. A team which is new to self-
management can find the 3Qs surprisingly effective. But my personal preference is for the team to start by asking one another if
they are confident they are going to achieve the Sprint Goal, then walk the board from top to bottom to discuss the status of
each item before finishing by asking if everyone is still confident of achieving the goal. It’s surprising how often the answer to
the same question will change within 15 minutes.
30
The entire Scrum Team is responsible for producing “done” useable product at
least every Sprint.

And don’t forget that they can create and release the latest version whenever
makes sense. Your team shouldn’t see the Sprint Review as a barrier to releasing
work. Some Scrum Teams release their work every day or even more frequently.

But teams do need to be encouraged to get an increment done every Sprint. Only
by understanding what is done and what is yet to be done can the stakeholders
and the Product Owner really understand their progress towards the Product
Goal. Almost done isn’t done, I’ve lost count of the times that something that is
only five minutes off being done still isn’t done by the end of the next Sprint and
the one after that! That’s why Scrum Teams only inspect done work at the Sprint
Review… you don’t know how long something will take until it is done.

Useable and done doesn’t always mean that it has to be released or actually in
the hands of your customers. It often does not make sense to release a product
every Sprint for many reasons. But the gap between done and released has to be
relatively straightforward.

To take an example from my personal experience, if it takes a team six months to

get a set of features “done” and then it takes them three years to release those
features to the customer, were they really done?

The other reason for focussing on producing a useable increment every Sprint is
as Jeff Sutherland once said, people don’t really know what they don’t want until
you show it to them.

31
Many teams still think of the Sprint Review as “just a demo at the end of the Sprint”. That’s not what the Sprint Review is about.

Every event is an opportunity to inspect and adapt. In the Sprint Review we invite key stakeholders to inspect what’s been done
up until this point and (crucially) adapt the plan for the product, i.e. the Product Backlog. This is the organisation’s opportunity
to discuss release schedules, budget, ROI, how the product is perceived, what’s going on in the marketplace and what’s
changing in the outside world. The outcome of a successful Sprint Review is an updated Product Backlog or at least a Product
Owner with a lot to think about!

But many teams don’t even bother inviting stakeholders to the Sprint Review. This is a mistake. If you aren’t checking in with
your stakeholders, if you aren’t showing them what’s actually done and getting feedback on what you should do next then you
have no transparency or understanding on whether you’re actually doing the right thing.

Some teams struggle to get stakeholders involved even through they want them to participate in the Sprint Review. I’ve always
taken a “build it and they will come” approach, in other words if you build something valuable and have something that actually
works then anyone who is genuinely interested and has a stake in the product will make time.

Note: not every stakeholder has to attend every Sprint Review. That would be a waste of time.

But if you aren’t involving your stakeholders and getting feedback at the end of every Sprint you aren’t limiting risk and I’d be
prepared for an unpleasant surprise when stakeholders eventually engage with what’s actually done.

Note: when we talk about “done” in the Sprint Review that doesn’t have to mean released to the customer. Your Definition of
Done should also reflect what the team are capable of. But the gap between done and released to your customers should not
be a complex or unpredictable or an overly lengthy process. If the Product Owner is happy with the increment during the Sprint
Review and asks for it to be released to customers this shouldn’t spark panic in the team.

32
At the risk of repeating myself, each Scrum event is an opportunity to inspect and adapt and the Sprint Retrospective is an
opportunity for the team to adapt their tools, technology and teamwork, their processes and their interactions. Ensure there
are concrete action points coming out of every Sprint and hold the team and yourself accountable for following through. Small
changes and experiments are encouraged. Imagine every week you come up with one small process improvement increasing
productivity by 2%. Within a year you’ll have improved by 100%. One tiny step at a time!!!

Ensure that the Sprint Retrospective is all talk and no action. Nothing will undermine trust in the process faster than the team
seeing that nothing changes.

Starting with a new team you might want to pick an impediment which is causing the team pain and solve that problem for the
team. Actions speak louder than words when you’re attempting to build trust.

If you fail with an action point then be honest and admit it. Even admitting failure can build trust. Everyone fails some of the
time!

A lot of Scrum Masters are mystified in the Sprint Retrospective. Whether the Sprint has gone well or gone badly the team
seems to have nothing to say. When asked to talk about the Sprint they just shrug. Think about the coder mindset for just a
moment. Most techies, taking coders as an example, are people who are passionate about technology. They’ll code all day and
then go home and code all evening on their own projects for free. This for me is a clear red flag that there’s a lack of trust. The
team don’t trust you or each other or they simply don’t believe things will change.

Once you’ve built trust with your team your might experience the opposite problem, they won’t shut up! Then it becomes a
matter of prioritising and focussing on what you can get done. It’s a good problem to have.

There are many facilitation techniques you can use including some Liberating Structures, Stop / Start / Continue, mood charts
and countless others. These are all good and worth experimenting with but meaningful discussions won’t happen without trust.
33
Product Backlog Refinement is about planning for tomorrow (next Sprint) whilst
also working today (towards the current Sprint Goal). In other words, you don’t
want to get to the end of this Sprint and achieve the Sprint Goal only to find you
don’t have any work ready for the next Sprint!

This is an activity that a lot of Scrum Teams might neglect and you might notice
this if they arrive at Sprint Planning appearing to be unprepared. One reason for
this might be that refinement isn’t a Scrum event and there’s no specific time
within the Sprint that the team have to do it. If you notice this behaviour with a
new team you might want to prompt them to ensure they have allocated time for
refining the Product Backlog or maybe even consider scheduling in some time
when convenient for the team to discuss upcoming work.

The outcome of successful refinement is “ready” work, i.e. items on the Product
Backlog that the team feel they understand and are confident they can get done
within a Sprint. Simply marking items on the Product Backlog as READY can help.

Try to avoid leaving refinement until the end of the Sprint. Typically refinement
involves talking about work on the Product Backlog, breaking it down into smaller
items and then possibly talking to stakeholders and subject matter experts about
exactly what is required. This can involve a lot of back and forth and if you leave it
until the last minute it often doesn’t get done.

One last thing, Product Backlog Refinement is the responsibility of the entire
team but if the Developers feel they don’t all need to be involved in every
decision, that’s fine. It’s up to them. They are the experts!

34
It’s very easy to fall into the trap of confusing the practices with the
framework because the practices are what people see.

Sticky notes. Kanban boards. Burndown charts. Jira. Planning poker. Epics,
user stories and story points. Scrums of Scrums. Velocity Charts!

These are all associated with Scrum and almost all Scrum Teams will have
done some of these at some point. But these are not Scrum, these are
practices that Scrum teams may use if they prove useful.

Scrum is an empirical framework based around small self-managing

teams, designed to provoke change by raising transparency and
encouraging the team to regularly inspect their plans and processes and
adapt them as they uncover better ways of achieving their goals.

To put it another way, if your team think they are doing Scrum because
they are moving sticky notes around on a board or standing up at 9am
every morning to go through the three questions they aren’t necessarily
getting the benefits from Scrum even though they are jumping through all
the hoops, attending the events, updating the artifacts and using all the
complimentary practices that other teams are.

This isn’t to say don’t use these practices. They’re popular for good
reason. But as a Scrum Master joining a team you should be very mindful
as to whether the practices your team are using are helpful in raising
transparency and inspecting and adapting your plans and processes.

35
There are many different frameworks out there for scaling Scrum across multiple
teams including but not limited to Nexus, Scrum@Scale, LeSS and SAFe. These are
all aimed at managing the additional complexity, dependencies and alignment
issues that come with adopting Scrum with multiple teams working on a single
product and the larger the product the more these issues will come into play.

If you are at the stage where you have a team that is possibly becoming “too large”
or you already have two or three teams working on the same product then you
don’t necessarily need to jump into using a specific scaling framework if the simple
principles from The Scrum Guide are working for you.

Note: Scrum doesn’t mandate a maximum team size, it’s more important that the
team is cross-functional, self-managing and small enough to be nimble.

One Product should always have one Product Owner and one Product Backlog. If
there is too much work for the Product Owner to handle they should delegate the
work rather than establish a Product Owner Team. You need a single person who is
accountable for vision and value.

Teams don’t have to synchronise their Sprints although it can make things tricky if
they don’t. They do have to produce a single, integrated increment at least once a
Sprint. If you don’t have a single integrated product or piece of value at the end of
the Sprint then you need to ask how long it will take to consolidate it before you
release it. And the honest answer is you don’t know until it’s integrated.

You might also consider suggesting a Scrum of Scrums where representatives from
the teams meet regularly to discuss dependencies in their work. It’s not Scrum but
like other complimentary practices, it might be useful.
36
Years ago I went on a training course by Data Warehouse guru Ralph
Kimball and he said something along the lines of... “You’re always selling.
You never know when you’re going to be stuck in an elevator with the
CEO or whoever and they’ll ask you or one of your team why you exist.
And if you can’t justify it then maybe your budget doesn’t get renewed
next financial year.”

This has stuck with me. And I’ve noticed that a lot of talented and capable
Scrum Masters struggle when they are asked a simple question such as
“Why should we do Scrum?”. They often don’t have a ready answer.

I’d argue that they should.

If I’m at a party and people ask what I do then I say I help technical teams
work together more effectively. Because if you have an “elevator pitch”
then it should be tailored to the interest of the person asking the question
and their concerns and the amount of time you have.

If I was talking to someone technical (a Developer) I’d focus on the value

to the business of delivering done working software, I’d include examples
of brilliant developers wasting weeks on excellent code that was never
used and I’d be honest about the trade offs and expectations.

If I was talking to a CEO I’d focus on customer satisfaction, risk, delivery

costs and overrunning deadlines and value. If I was feeling especially
brave maybe I’d even start by asking what their biggest concerns were.

My advice is, practice your elevator pitch for Scrum. You never know!
37
When asked what was the biggest factor in the success of an Agile transformation
a very common answer given is “Growth Mindset”.

But what does this mean and how can you help nurture this?

A fixed mindset is one where people have a clearly defined idea of things they are
good at and things they are bad at. This encourages these people to focus on doing
the things they are “good” at and avoid even attempting the things they perceive
themselves as “bad” at.

Unfortunately this mindset can seriously undermine Agility.

Someone with a fixed mindset might say “I can’t do this.”

Someone with a growth mindset might say “I can’t do this… yet.”

As Scrum Master you can nurture a growth mindset by encouraging, questioning

and challenging.

When someone says they can’t do something - ask what it would take for them to
learn that skill. When someone says they can’t help with a task - ask what could
they help with or what would it take for them to help a little. When someone says
it would take too much time - ask what small step they could take to learn
something new. When someone asks why they should - ask them if they would like
the team to help them sometimes.

Then one day you’ll overhear someone say “I can’t do that” and then add “yet”
and you’ll know that maybe you’re winning.
38
How do we build trust? How do hedgehogs make babies? Very carefully.

Trust can take months to build but can be broken in moments so you
might want to start with some of the following…

• Listen more than you talk

• Try to understand your team as people and unique individuals
• Always be open and honest
• Follow through on what you say you will do
• Go first and be willing to share
• Be honest about your own short-comings
• Ask for help
• Volunteer when you make a mistake
• Never say something about someone you wouldn’t say if they were in
the room
• Offer to help
• Do something with the team that isn’t work related
• Learn something about the people you work with
• Talk about cultural differences

Self-managing teams are more dependant on collaboration,

communication and culture than traditional micro-managed teams hence
they are more susceptible to “bad apples”. It’s difficult to overstate how
the toxic behaviour of one team member can undermine the
performance of the entire team. Don’t stand by and let it happen.

39
There’s a Hollywood cliché that if we shout at people loud enough and tell them
they can’t fail then they’ll try just that little bit harder and they won’t make any
mistakes. In real life with complex product development this just doesn’t work.

Make no mistake, sooner or later you will fail. Probably sooner. Because building
complex products is inherently risky. In fact failure is part of the process. Every
successful innovator has failed. Even great teams fail. But what they have in
common is they all use those failures to learn and improve.

If you start in an organisation where “failure is not an option” then you have a
problem. You need to ask what sort of culture and mindset this is creating. Teams
will avoid taking risks, teams will avoid experimenting, teams will always take the
safe and conservative option.

Fear of failure stifles creativity, experimentation and innovation.

This isn’t to say that we encourage the team to accept failure all the time. If a team
is failing to achieve their Sprint Goal every Sprint then that is probably a basic
competence problem and something you can help them with. But most teams are
striving to do the best they can. In fact, in my experience, if technical people have
one common flaw it’s that they over-commit. They take on too much work. They
over-estimate what they can get done because it’s natural to not factor in all the
tasks involved in getting complex work done.

A great Scrum Master helps a team push their boundaries, being comfortable with
risk and occasional failure whilst always striving achieve something… out of this
world!

40
Don’t expect this to happen overnight. Competence at Scrum will
probably take months or years rather than days or weeks. And that’s just
the beginning.

Scrum is designed to provoke change.

You don’t change Scrum to fit the organisation, although that would be
nice and easy. You use Scrum to change the organisation, it’s plans and it’s
processes. But change is uncomfortable and difficult because it pushes
people outside their comfort zones.

People often resist change for a variety of reasons.

Organisations are made up of people(!)

As a Scrum Master you’ll need empathy, patience and persistence.

Always try to be humble and curious and start from a place of accepting
that you don’t always have all the answers.

If you remember all of this then you can still add value to the team and
maximise their chances of success with Scrum.

41
“ Your use of Scrum will expose every reason why your enterprise has
trouble building products. Scrum will keep exposing the problems until
they are fixed.

Whenever [the rules of Scrum] cause a conflict with existing practices, an

impediment has been encountered and made visible. The enterprise has to
choose whether to change to remove the impediment or to give up on
some of the benefits.
Ken Schwaber
The Enterprise and Scrum

“Jeff Sutherland
Change or Die.

The Art of Doing Twice the Work in Half the Time

 www.agileskills.com

Duncan Maddox is a licenced Scrum.org Professional Scrum Trainer with 30 years experience building
complex products and teams.

If you have found this eBook useful then you can follow me on LinkedIn
www.linkedin.com/in/scrum-duncan/

My public Scrum.org training course schedule is available at

hwww.scrum.org/duncan-maddox

I also talk about life, the universe and Scrum with Jim Quantrell on the following channel
www.youtube.com/c/TheScrumMastersGuidetotheGalaxy