Situational Scrum
Situational Scrum
Scrum Mastering
Leading an Agile Team
by Mike Cohn
A few years ago, after I had hit a number of golf balls into a lake,
the friend I was golfing with offered me some advice. Now my
friend isn’t a better a golfer than I am, but that didn’t stop him from
interjecting his opinion. “The problem,” he said, “is that you need to
hit the ball farther.” He might as well have told me that the problem
was that I was taking too many shots to get the ball in the cup. Of
course I needed to achieve more distance. But how?
A better way to understand how Scrum Masters can best lead teams
that are trying to become agile is to first understand what the team
needs in terms of leadership, and then look at four different ways to
provide that leadership.
Unwilling or
R1 Unable
Insecure
Willing or
R2 Unable
Confident
Unwilling or
R3 Able
Insecure
Figure 1. The four readiness
levels of the situational Willing or
R4 Able
leadership model. Confident
!"#$%#"&'%()!*+$,)-%.#/+"'01)2/%3"'0)%')40"(/)5/%, 6
According to Hersey, leaders need to adapt their behavior to fit a
team’s readiness level. In other words, a Scrum Master working with
an able and willing team will lead her team in a different manner than
someone working with an unable, unwilling team. Hersey suggests that
good leaders adjust their leadership behaviors along two dimensions:
task behavior and relationship behavior.
Leader Behaviors
(high)
Participating Selling
(R3) (R2)
Relationship Behavior
Delegating Telling
(R4) (R1)
(low)
!"#$%#"&'%()!*+$,)-%.#/+"'01)2/%3"'0)%')40"(/)5/%, 7
For example, an R1 team, which is unable and insecure, will need more
task guidance from their Scrum Master. The Scrum Master of this
team will rely less on two-way communication (a high-relationship
behavior) and instead favor one-way communication. Scrum Masters
always need strong interpersonal skills but an R1 team (unable and
insecure) needs a high level of task guidance so they can gain enough
confidence to participate constructively in two-way communication
as an R2 team. In contrast, R3 and R4 teams, with their high levels of
ability, need a much lower degree of task direction from their Scrum
Masters.
The rest of this paper will consider some specific things a Scrum
Master should do when leading a team in each of these quadrants.
!"#$%#"&'%()!*+$,)-%.#/+"'01)2/%3"'0)%')40"(/)5/%, 8
:;1)5</)5/(("'0)!*+$,)-%.#/+
!"#$%#"&'%()!*+$,)-%.#/+"'01)2/%3"'0)%')40"(/)5/%, 9
this type of team, do not need to be automated but they do need
to be done.
Expect that, in the beginning, there may not be many tests and what
tests do exist may fail often. In most cases, however, over the course of
a few weeks the number of tests will grow and the number of successful
builds will increase. A few weeks of receiving the positive feedback of
multiple successful builds (and the reduced rework this leads to) can
work wonders for the morale—and confidence—of the team.
A few years ago, I was handed a classic R1, unable and insecure team.
The team members were almost all COBOL programmers working
on PCs. The company had just been acquired and the previous
management had repeatedly told the team members they weren’t
capable of working in newer or more interesting technologies.
The team included some very smart programmers but after a few years
of being treated as they had, they’d lost all their confidence and their
skills had fallen out of date. After a few months of me
providing very specific guidance to the team about
what technologies to use, how to work, and so on,
confidence was restored. The once-dysfunctional
team had advanced to the R2 quadrant.
!"#$%#"&'%()!*+$,)-%.#/+"'01)2/%3"'0)%')40"(/)5/%, B
:61)5</)!/(("'0)!*+$,)-%.#/+
!"#$%#"&'%()!*+$,)-%.#/+"'01)2/%3"'0)%')40"(/)5/%, C
anyone else who is tempted to focus only on speed) that if you get
on the highway and floor it to 120 miles per hour, you’ve got a good
chance of getting a ticket or being in an accident. Either way, you
won’t end up at your destination any faster than if you’d averaged a
safe, high-quality 70 miles per hour.
!"#$%#"&'%()!*+$,)-%.#/+"'01)2/%3"'0)%')40"(/)5/%, F
:71)5</)K%+#"*"@%#"'0)!*+$,)-%.#/+
Instead of making decisions for the team with its input (as in the R2/
selling quadrant), encourage the team to make its own decisions.
Do this as soon as possible—even before the team recognizes their
newfound ability. In the face of these increased responsibilities,
teams in the R3 quadrant typically return temporarily to feeling
insecure. But, unlike an R1 team, the R3 team is highly skilled and can
quickly transition to an R4 team.
To help the team transition into making its own decisions, move
L"#<)%'):7)#/%,G) completely out of the decision-making process. Be there to
encourage and support the team but make it completely clear to the
/'*&$+%0/)#</)#/%,))
team members that the decision is theirs. Naturally, the team may
#&),%?/)"#.)&>') make some mistakes. But, so what? Team members are continuing to
3/*"."&'.A) learn and their level of performance is typically so far ahead of where
it was at R1 that a few mistakes are a small price to pay.
!"#$%#"&'%()!*+$,)-%.#/+"'01)2/%3"'0)%')40"(/)5/%, J
There are a number of things the Scrum Master can do in this regard.
Last but not least, make sure the team is always working on the
highest-valued work possible. One way to do that is to offer to work
with the product owner to prioritize and adjust the product backlog
as the project progresses.
!"#$%#"&'%()!*+$,)-%.#/+"'01)2/%3"'0)%')40"(/)5/%, ;M
:81)5</)N/(/0%#"'0)!*+$,)-%.#/+
!"#$%#"&'%()!*+$,)-%.#/+"'01)2/%3"'0)%')40"(/)5/%, ;;
to be made someday, but not in the second week of the project.
So let the team make decisions but coach them and advise them to
defer decisions until as late as possible.
This is just one example and there could be many others. The key
distinction here is that the traditional project is managed with the sole
goal of meeting a deadline with a specified set of features. The agile
project may, of course, have deadlines with promised functionality,
but the sustained throughput of the team over the longer term is also
important.
!"#$%#"&'%()!*+$,)-%.#/+"'01)2/%3"'0)%')40"(/)5/%, ;6
K$##"'0)!"#$%#"&'%()!*+$,)-%.#/+"'0)5&)S./
Leading is the sum of every interaction Scrum Masters have with their
teams: what they say, what they don’t say, how they say it, how they
listen. Being a good leader of a Scrum team doesn’t involve yelling
“Damn the torpedoes!” Nor does it entail sitting quietly apart from
the team and listening to the daily scrum updates. Instead, being a
good agile leader—a good Scrum Master—is something that must be
learned, often times alongside teams that are learning themselves
how to become agile.
!"#$%#"&'%()!*+$,)-%.#/+"'01)2/%3"'0)%')40"(/)5/%, ;7
software at the end of each iteration, team members will naturally
look for ways to improve their skills.
Teams that have grown significantly in ability are ready for a more
participating leadership style. However, when teams must make
decisions for themselves, they tend to become nervous, wondering
if their newly-acquired skills are sufficient. Guide R3 teams through
this transition by supporting them in their decisions and by focusing
your own attention on the longer-term (3-6 month) horizon, allowing
the team to devote all of its attention on the current sprint.
T'#+&3$*"'0)%'3) One way to do this is to ensure that sprints remain focused on the goals
UH̰QLQJWHFKQLTXHV of the next release, even as the work of each sprint is reprioritized at
its start. At the same time, make sure the company selects high-value
%#)#</)+"0<#)#",/)
work for the team by working with the product owner to ensure the
=&+)%)0"H/')#/%,)".) product backlog is properly prioritized.
/../'#"%(A
Some Scrum Masters are lucky enough to work with an R4 team,
which is skilled and willing, ready to step up to even greater levels
of responsibility. In those cases, adopt a delegating leadership style.
On Scrum projects, that involves a focus on maximizing throughput
over a horizon exceeding that of one project. It also means helping
the team learn to defer decisions so that options
remain available as long as possible.
!"#$%#"&'%()!*+$,)-%.#/+"'01)2/%3"'0)%')40"(/)5/%, ;8
4UOS5)-TVW)XOYZ)
Mike ran his first Scrum project in 1994, and has been a vocal proponent
of Scrum ever since. With more than 20 years of experience, Mike was
previously a technology executive in companies of various sizes, from
startups to the Fortune 40.
!"#$%!$&'(&
!"#$%#"&'%()!*+$,)-%.#/+"'01)2/%3"'0)%')40"(/)5/%, ;9