Good-vs-great-agile-teams

good vs. great
From good, sustainable agile
teams to great agile teams

phases of team
development

agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.

Tuckman (1965)

performing
Focus on task
(productivity)

norming

forming

storming

Relationship

after starting a team, are your
poll agile teams sustaining (good),
performing (great) or regressing?

Tuckman (1965)

performing
Focus on task
(productivity)

norming
sustaining

forming

storming regressing

Relationship

change is not the same as progress

The last 100 years has
seen lots of improvements
in golf clubs

but golf scores have
stayed the same

empowerment used to mean self-management


today self-organization trumps self-management


how to lead through
change


Know what we don’t know...

Ibn Yamin Faryumadi One who doesn't One who knows
know, but knows and knows that he
(Persian-Tajik poet)

knows
that he doesn't knows...
said there are four know... This is a man of

personal awareness
This is an illiterate knowledge; get to
types of men: man; teach him! know him!

One who doesn't
doesn’t know One who knows,
know and doesn't
but doesn't know
know that he
that he knows...
doesn't know...
This is a man who's
This is a dumb man;
unaware, so bring it
and would be dumb
to his attention.
forever!
doesn’t know knows
personal knowledge

situational leadership (Hersey, Blanchard)

The Hersey-Blanchard supporting
coaching
for people with:
Situational Leadership for people with:

a lot
high competence
some competence

supportive behaviour
Theory rests on two variable
commitment
some commitment
fundamental
concepts;
• leadership style and delegating directing
• the individual or for people with: for people with:
little

high competence low competence
group's maturity high commitment high commitment
level
little a lot
directive behaviour

Shu: Learn the basics - focus on following
steps exactly
Ha: Explore the principles through guided
deviations from the basics
Ri: Adapt within the principles through self-
directed experimentation

(c) Alistair Cockburn 2000-2006


balance directive and
supportive actions
• let the team experience the
need, not just talk about it
• there are priorities to learning
• plan situations, don’t wait for a
need to emerge


a newly launched
agile team
• 1-3 sprints

• shared team commitment

• emerging xp practices

• transparent impediments

• balanced feature development
and tech debt removal


the team crashes?

• change is often painful, requiring
sacriﬁce before the reward
• pain avoidance, often a result
of no strong direction
• inside the team:
• new incremental changes
that violate core principles
• outside the team:
• management intervention as
murder or manslaughter


signs of regression


core concepts underpinning self-organization

shippable
product
team
commitment

feedback
cycles


core concepts underpinning self-organization

personal backlog items,
parallel and individual work, us shippable
& them vocabulary
product
partial or locally-optimized
team delivery avoiding
commitment organizational pain-points

feedback
cycles anything that lengthens
feedback loops, or eliminates
them altogether

e.g. no daily standup
...because
• I need time to develop
• we already know what everyone
is doing
• its just a status reporting meeting
• tasks take too long - nothing
changes within only one day

Potential indicators of
something more fundamental:
• lack of information
• pain avoidance


crossing your arms shouldn’t
a little bit of participation feel this awkward


leadership challenge
“However most of the high-
performance teams were not
manager-led teams.

They were teams where the
management had deliberately
stepped back, or was
inattentive or where one reason
or another was totally absent,
thus enabling the team to self-
organize.”

Steve Denning


management attitudes that kill performing teams

sometimes its
murder - death
by intent to kill

sometimes its
manslaughter - death
by negligence


how to destablize a high-performing team
• are high-performance teams fragile and short lived, prone to self-
destruction?

• no – the reality is such teams are often the victim of management practices
that result in what Tom Demarco & Tim Lister refer to as teamicide.


• are high-performance teams fragile and short lived, prone to self-destruction?


• sometimes it’s murder

• managers can feel threatened by teams that break rules of the prevailing
corporate culture and disband them, in order to preserve the status quo


• are high-performance teams fragile and short lived, prone to self-destruction?


• sometimes it’s murder

• managers can feel threatened by teams that break rules of the prevailing
corporate culture and disband them, in order to preserve the status quo

• sometimes it’s manslaughter

• management misunderstands the high-performance team or its mode of
operation and does things that unintentionally eliminate high-performance


sustaining progress
• stable progress dependent on
learning new skills - focus on
process/practices, not principles

• become very good at what they
do, but miss the continual
practice of change

• still inertia to change - tend to be
dogmatic about rules, not agile

• typically teams replace one
institutional process with another


sustaining agile teams quickly regress to the mean

replace one deﬁned process with another
dogmatic and selective application of new rules
change practices for comfort rather than results
learn little in way of new skills


growing learning
teams
• strong product and quality
ownership

• builds mental muscle for
adapting to change

• continually practices small
change, challenging status quo

• focus on accelerated learning
practices

• hungry for responsibility


great agile teams are continually changing

build out good practices without compromise
incorporates holistic view / guidance
leadership creates environment for success


realigning regressing
agile teams
• get commitment to 30-60 days
• educate and inform
• the +15 team framework
leads discussion on agility
• move at speed
• nay-sayers can be
distracted by rapid progress
• avoid miss-selling any
progress is really positive


ct
du
Pro
ble
pa
S hip n w
ga do and
rin urn ts
t b poin ly
elive rin
sp ation ts o done
n
D is a estim . Poin are
ere ly Is
Th t uses d dai n PB
tha date whe
p n ly
is u n dow us
rs bu r uo e
io tin nd th arni
av of on
s c ality a ive L ctiv
e
B eh p i
rint h e to BIs eam g qu e Ac ospe
t
Sp mt P et
fro 6-10 Th rovin ith th e retr
a kes east e into imp ess w ing th
m t at l e siz c
pro le du
r
tea g n it
s
he acklo e sam sprint
T b Cy
c
rs o a s
e out th eek ive at le
th b w del th f
of a ry 1-2 m
tea Is a
t am t wi tio o

+15 team framework
kl og ve the 3 PB s e te itmen ty (ra at
ac e Th m i sti m
int, - Ii bil
aB ±2 spr st 2 PB com dicta tted e
ri ng s 7 al,
ha n the at mo il the re mmi
p o
pa eam ctio ring n nt
Pre D u r k s o i me u to c ve
nt t s-fun ry to t of e
me os a
ss int wo one nd rs a
op cr to o
l
eve d is s nec spr
e any e ni
n t the
e
i ve
ed n ll a don ow ugh At m del e pro
Th ple a e ski side n d ll eno , l
o ll th
pe a Ii n ro ke a
m ay s oard tea ppab or u
h r a PB , e b are s 1-2 d taskb hi sed
• the +15 team framework leads wit ve n h, r s
isio r pitc Is a t in 's rele
a
del
i tv
uc evato PB ks tha eted team
l
rod el ents e tas comp n the
a p an ay dc
discussion on agility be ked o
m lu
e is ed as quire ss va yd are
er s
Th res re sine tr ac ver , for a to Sh vely
t of se d p i
exp a lis by b
u eet boar ndu act exa
m m task n) sta
• what does the core scrum
d og for d
and ritize ack
l
e te
a e
mi ies n
p rio uc
t b ll 1-2 Th und th x 15 ctivit tre
od s to fi e
pr BI ro t (ma y's a
a r
framework look like
th da
is a P eet sho the t
e n M.
ere nough all m y lan im
Th e t d p ed the S
h ha ea p
wit ints, t of R n im by kly SM
• allows progress to be tracked s pr ition
De
fi n m
t
ee .
PO PBI tima m
s tes Th kl
c
is a wned e quic or the
ere og o s ar am
ent e te
and oom m es o the ba edim by th
• e.g. review every sprint e te
m gr
a o
t
Th ularly in th mmit
a
e te ting
t p ed
Im olv
res
e o
• brings clarity to the what is
reg ryon ore c
e
Ev s b e
f has O
ne
P BI f Do the P of a
n o en sists
expected of team eD
e
itio twe
fin d be d con ints
ee
Th n agr am, to 10
an po
e
be the of te up
and cklist
che


+15 Team
Preparing a Backlog Sprint Behaviors Delivering a Shippable Product

The development team has 7±2 The team takes from the top of There is a sprint burndown
people and is cross-functional, the backlog at least 6-10 PBIs that uses estimation points and
with all the skills necessary to of about the same size into is updated daily. Points only
deliver a PBI inside a sprint every 1-2 week sprint burn down when PBIs are done

There is a product vision, During the sprint, the team The team is continuously
expressed as an elevator pitch, works on at most 2-3 PBIs at improving quality and the
and a list of requirements any one time until the PBI is process with the Active Learning
prioritized by business value done Cycle during the retrospective

There is a product backlog PBIs are broken down into The team delivers on its
with enough PBIs to fill 1-2 tasks that are small enough to commitment with at least 90%
sprints, that all meet the be completed in 1-2 days, predictability (ratio of accepted
Definition of Ready tracked on the team's taskboard to committed estimation points)

The team and PO meet The team meets every day At the end of every sprint the
regularly to groom PBIs. around the task board, for a team delivers a potentially
Everyone in the team estimates short (max 15 min) standup to shippable product, that can be
PBIs before committing to them plan the day's activities released or used internally

The Definition of Done has There is an impediment Shared code ownership is
been agreed between the PO backlog owned by the SM. actively pursued by the team,
and the team, and consists of a Impediments are quickly for example, by pairing or
checklist of up to 10 points resolved by the team or the SM trending the bug count to zero


software delivery
doesn’t have to be a
long, uphill climb with
no end in sight...
recognize new paradigm of
software delivery


delivering working
software can be
empirically tested
every few steps
delaying veriﬁcation against
planned progress is no longer
acceptable


focus on outcomes
over outputs
point teams at small changes to
the whole, not steps in the process
success is deﬁned by outcomes,
not the amount of work done


agile methods for
small teams
little divergence from common
approach
shared artifacts emerge naturally


Focus on outcomes
not process
Address technical debt
in the sprint
Capture the right
artifacts
Institutionalize
knowledge sharing


agile methods at
scale
• teams diverge from common
approach
• artifacts harder to share


•teams adapt to
•development need
•experience curve
•each team adapts in a different way
•legislating an approach cripples value delivery
•deﬁne working practices over theoretical
approaches


Focus on framework
and boundary objects

Guide self-awareness
not maintain status quo

Share success not best
practices


Growing Agile Teams team name:

Specialist knowledge shared
Acceptance test-driven dev
Limited manual testing
STEP 4. Scale Automated testing of NFRs
grow knowledge, share learning, Communities of Practice

Focus on framework
expand capabilities Shared Definition of Done
Stable and verifiable builds
Cross-cutting concerns
Entire team works on release

and boundary objects
Everyone experiences SM
Team owns environment
Velocity guides release
Business value drives work
Visible measure of value
Swarms on committed PBIs
Owns external dependencies
STEP 3. Maximize Value
organize to deliver maximum value Reduces technical debt
Grow engineering practices
Automated PBI testing

Team takes 6-10 PBIs Guide self-awareness
Predictability over 90%
Business value understood
PBIs done in priority order

not maintainteams first focus quo
status on
PBIs reviewed as done
STEP 2. Gain
Experience Shared code ownership
people, process and work all settling
in, focus on learning
Technical debt identified
Bugs actively fixed
agile
1-3 improvement actions
Release Definition of Done
smoothing flow and
enhancing quality, leading to
Cross-functional Teams
Working Agreement maximizing of value delivery
Regular backlog
PBIs for 1-2 sprints
grooming
Impediment backlog
STEP 1. Organize PBIs broken into tasks
Active Learning Cycle maximizing value
preparing the structures, work and Transparent team
Definition of Done

practices
people capacity
Definition of Ready enhancing quality
Daily stand-ups
Potentially shippable
Sprint burndown
Vision and requirements
smoothing flow
Focus on 2-3 PBIs

more each stage acts as a scaffold, offering guidance and more
directive support, for different phases of a team’s agile journey guiding
copyright 2011We advise, trainltd
agile42 | agile42 consulting and coach companies building software
the accompanying Growing Agile Teams worksheets provide more details behind the checklist 2007 - 2009.
www.agile42.com | All rights reserved. Copyright © for each step

Auditing agile methods at scale

practices


thank you

dave.sharrock@agile42.com
skype: dave.sharrock
follow us on: @agile42
follow me on: @davesharrock

Good-vs-great-agile-teams

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (6)

More from Dave Sharrock

More from Dave Sharrock (20)

Recently uploaded

Recently uploaded (20)

Good-vs-great-agile-teams