scrum pitfalls (ii)...• scrum of scrums for other specialized roles as needed (eg. architects, ux,...
Post on 26-May-2020
10 Views
Preview:
TRANSCRIPT
© 2
013 S
cru
m I
nc.
© 2011 Scrum Inc.
Scrum Pitfalls (II) And How to Navigate them Safely
Hosts: Alex Brown Christine Hegarty
© 2
013 S
cru
m I
nc.
: Who We Are
Scrum Inc. is the Agile leadership company of Dr. Jeff Sutherland, co-creator of Scrum. We are based in Cambridge, MA.
We maintain the Scrum methodology by: • Capturing and codifying evolving best practices, • Conducting original research on organizational behavior • Adapting the methodology to an ever-expanding set of
industries, processes and business challenges
We also help companies achieve the full benefits of Scrum through our full suite of support services: • Training (Scrum Master, Product Owner, Agile Leadership, webinars, etc.) • Consulting (linking Scrum and business strategy, customizing Scrum) • Coaching (hands-on support to Scrum teams)
• Publishing and new content development
Find out more at www.scruminc.com.
We run our services company using Scrum as the primary management framework, making us a living laboratory on the cutting edge of Enterprise Scrum
© 2
013 S
cru
m I
nc.
2
Agenda
• Introduce model for Scrum effectiveness and associated pitfalls
• Discuss the A3 Process as a tool for identifying and overcoming typical pitfalls
• Review 7 common Scrum pitfalls related to
Removing Impediments and Leadership
• Q&A
© 2
013 S
cru
m I
nc.
Sprint
Retrospec4ve
A Simple Model for How Scrum Works And the Pitfalls that Can Cause it to Break Down
Velocity
DO
NE
!
RE
AD
Y!
Remove Impediments Daily
Standup
• Daily Standup and Retrospec3ve are
dysfunc4onal
• Velocity not tracked, known, or
measured in hours
instead of points
• Insufficient cross‐
team coordina3on
L Leadership
• Team over‐commits
(or is commiBed)
• Team working
backlog individually
rather than together
• “Found work” interrup4ng the
Sprint
• PO func3on not well defined or
under‐resourced
• Team not inves4ng
enough 4me to
refine backlog
• Stories not broken down enough or
not independent
“ver3cal slices”
Today’s Focus Today’s Focus
• Leadership expects waterfall repor3ng
• Leaders prefer to
hide dysfunc3on vs.
address it
• Leadership not priori3zing
• Leadership not
suppor4ng
impediment removal
© 2
013 S
cru
m I
nc.
Important to Address Root Causes Rather than Just Treat Symptoms
• The A3 is a light-weight problem-solving tool designed to identify and address root causes
• Came out of Toyota’s continuous improvement process
• Named for size of paper (11x17)
© 2
013 S
cru
m I
nc.
Daily Standups and Retrospectives are Ineffective
• Velocity is not increasing • The Daily Scrum feels like a “status meeting” • Team members never have any impediments
• Team does not know its top impediment • The Retrospective meeting is skipped because it
“wasn’t useful” • Team processes have been static for several
Sprints
Typical symptoms
• Team members never have impediments • Working hard to finish work and not investing
enough time in continuous improvement
• SM not facilitating needed introspection • Team members are hesitant to name issues
• There is a fear of conflict • Team lacks needed trust to face
underlying issues
• Retrospective skipped • Team doesn’t perceive value to retrospective
• Retro does not drive to actionable results • Identified impediments are not removed
• SM not following up on impediments
Root causes
SM owns identifying/removing Impediments • Additional training or coaching for SM • Surface team blockers at the daily meeting and
push actively to resolution • Track impediments and show impact of removal
Implement the Happiness Metric • Great tool to probe for impediments and
underlying root causes at Retrospective
• Entire team discusses the top root cause and identifies counteractions
Confront Interpersonal Issues on Team • Make meetings a “safe” environment to clear the
air and voice future issues
• Accept that some team members may not fit
What to do about it
• Velocity grows ~10% each Sprint & team has fun • Team leaves each Retro with one actionable
process improvement and acceptance criteria
• SM maintains visible impediment backlog • Daily Scrum has rich and interactive discussion
around making process easier • The Team can bring up impediments without fear
of inciting an emotional backlash
Target end-state
Impediments
Re
ad
y
Do
ne
© 2
013 S
cru
m I
nc.
Team Uses Sprint Retrospective to Focus on Removing “Waste” to Improve Efficiency
Muda (Wasted Effort)
Mura (Variability Waste)
Muri (Emo4onal Waste)
In‐Process Inventory
Overproduc4on
Extra Processing
Transporta4on
Wasted mo4on
Wai4ng
Correc4ng Errors
Unevenness
Inconsistency
Absurdity
Unreasonableness
Overburden
Par4ally implemented user stories, bugs or incomplete
work that cannot generate business value
Working on low‐value features that customers don’t care
about rather than saving capacity for high‐value work
Unnecessary management processes, redundant quality
checks, relearning others’ work
Handoffs across roles, teams, divisions and so on
Switching back and forth between tasks or “mul4‐
tasking,” delays from interrup4on of the sprint
Delays, dependencies, capacity imbalances resul4ng from
specialized capabili4es without cross‐training
Fixing bugs or other errors that should have been caught
earlier or systema4cally avoided to begin with
Varying granularity of work between team members
Different defini4ons of “Done” and process varia4ons that
make defining “poten4ally shippable” product difficult
Stress due to excessive scope
Stress from an expecta4on that heroic ac4ons to save the
day are normal
Stress due to excessive workload from “overhead” tasks
Sources of waste From Taiichi Ohno’s “The Toyota Way”
7
© 2
013 S
cru
m I
nc.
Pattern: The Happiness Metric Focusing on Team Happiness to Guide Improvement
For each person:
1. On a scale of 1-5, how happy are you with your role in the company?
2. On the same scale, how happy are you with the company?
3. What specific events or activities increased your happiness?
4. What specific events or activities decreased your happiness?
5. What would increase your happiness moving forward?
For the team:
• What would make the team as a whole happier in the next sprint?
• Identify the top priority for the team
• Execute the pattern Scrumming the
Scrum
The Happiness Metric is included as part of the Sprint Retrospective meeting…
© 2
013 S
cru
m I
nc.
Velocity is Not Tracked or Measured in Hours Rather than Story Points
• Team often fails sprints or needs to abort • Team misses major product releases • Team doesn’t know its velocity
• Sprint Planning takes longer than an hour • If known, Velocity is not increasing over time
• User Story estimates are often significantly off
Typical symptoms
• Team brings too much work into each Sprint or sets unrealistic delivery deadlines • Teams don’t use “Yesterday's Weather” Pattern
of only planning as much work as they have completed in the past
• External deadline pressure applied • Team does not track Velocity
• Team does not fully appreciate its utility
• Team is “too busy” to estimate • Team discovers a lot of work during Sprint
• Team estimates in hours, not points • Team thinks hours are more accurate • Team thinks hours are easier
• Already working with hours based on team’s hourly billing – inertia
Root causes
• Estimate all backlog items that need to be completed, using Agile estimation methods • Use Story Points estimating relative size
• Planning Poker rapidly harnesses “wisdom of the team” for more accurate estimates
• Update estimates as team learns more • Track the Velocity, or total points completed, at
end of each Sprint
• Useful for planning future work and measuring process improvement over time
• Never plan for the Team to produce more output per Sprint in the future than it has in the past • Just be happy when it does
What to do about it
• The Team knows its Velocity • The Team bring only as much work into each
Sprint as it has actually completed on average
over previous three Sprints • Short and effective Sprint Planning meetings (1
hour or less per week of Sprint) • Team Velocity increases at ~10% per Sprint • Team ultimately becomes Hyper-Productive
Target end-state
Impediments
Re
ad
y
Do
ne
© 2
013 S
cru
m I
nc.
Knowing Output and Taking Time for Process Improvement Enables Hyper-Productivity
Points
Sprint
Source: Scrum Inc. performance data
Raw Scrum Inc. Velocity History (not adjusted for fluctua4on in team capacity by sprint)
Holiday 2011
12x output with 3x FTEs
= 4x produc4vity
© 2
013 S
cru
m I
nc.
Why Points are Better Than Hours
1. Repeated studies have shown estimates in points are more accurate than
estimates in hours
3. Time is finite. There are a fixed number of hours in a day, so a velocity based on
hours can’t increase!
2. Estimating in hours undermines the fundamental purpose of velocity…
Measuring Output!
Sprint
Velocity
(hours)
© 2
013 S
cru
m I
nc.
Insufficient Cross-Team Coordination
• Inter-team dependencies impede work • User stories appear in multiple backlogs,
resulting in duplicate work
• Work discovered within Sprint by one team, that is needed by another Team to progress
• Outputs from one team don’t integrate well with those of another
• Release dates are missed or hard to estimate
Typical symptoms
• Missed release dates • Inter-team dependencies impede work • Impediments that span teams not identified
• Teams do not communicate or coordinate efforts
• No mechanism for cross-team process coordination
• Same story appears in different backlogs or key
story is missing from all backlogs • Teams do not integrate work or coordinate
• Teams are pulling from separate backlogs • POs are not collaborating on backlog
• No mechanism for central Product
Owner coordination
Root causes
No mechanism for cross-team process and product coordination • Establish Scrum of Scrums to coordinate team
process and remove impediments as they are identified
• Create a single product backlog that all teams pull from, and hold regular PO meetings to refine unified backlog and plan releases
• Scrum of Scrums for other specialized roles as needed (eg. Architects, UX, QA, etc.)
• Provide Shared access to team metrics and charts
What to do about it
• Saturation of communication between Stakeholders, POs, and Teams
• All teams pull work from a single product
backlog, which is curated by all POs • Scrum Teams have a regular and established
method of communication with each other • Inter-team dependencies are identified ahead of
time and addressed efficiently
Target end-state
Impediments
Re
ad
y
Do
ne
© 2
013 S
cru
m I
nc.
Scrum Master and Product Owner Functions Scale Differently
Scrum Master Product Owner
• Share best prac4ces
• Collec4vely solve problems &
remove impediments
• Maintain clear and consist product vision
• Optimize business value • Respond decisively to changing
market
Team
Scrum of Scrums
Scrum of Scrum of Scrums
PO
CPO
PO PO
CPO
PO
CPO
Product PO team
Component PO team Component PO team
© 2
013 S
cru
m I
nc.
How Spotify Manages Cross-Team Coordination
PO
T
T
T
T
T
Squad
Chapter
Chapter
CPO
Tribe
PO
T
T
T
T
T
Squad
Chapter
Chapter
CPO
Tribe
Source: Henrik Kniberg and Andars Ivarsson
Guild
PO
T
T
T
T
T
Squad
PO
T
T
T
T
T
Squad
PO
T
T
T
T
T
Squad
PO
T
T
T
T
T
Squad
PO
T
T
T
T
T
Squad
PO
T
T
T
T
T
Squad
© 2
013 S
cru
m I
nc.
Leadership Expects Waterfall Reporting
• Team velocity is stalled and not increasing over time
• Significant number of backlog points devoted to
reporting activities that don’t add customer value • PO/SM asked to make frequent progress reports
to leadership • Reporting focused on actual progress versus
plan, where plan is considered fixed.
Typical symptoms
• Team progress limited by excessive time devoted to reporting • Extensive manual reporting not part of the
normal Scrum workflow • Velocity, backlog and burndown provide
more actionable data more seamlessly • But reporting required by Leadership
• Leadership wants to maintain visibility
• Leadership believes extensive reporting only way to achieve visibility
• Leadership doesn’t understand Scrum, how to use Scrum metrics
• Changing tools from something that
has “worked” in past is scary
Root causes
Leadership doesn’t understand Scrum or Scrum metrics • Provide leadership training on Scrum, including:
• Why use Scrum? • How to accomplish traditional leadership
goals in Scrum • How to work with and get most from teams • What is mgmt’s responsibility to teams
Change is inherently scary • Build the business case for change, using velocity
and points devoted to reporting to highlight cost • Suggest a short-term pilot on one project to help
get comfortable with new approach
What to do about it
• Leadership has access to real-time flow of velocity, burndown, value per point, and other data through a physical or online dashboard
• Leadership can make better real-time decisions without needing to wait for an update meeting
• Teams have no additional effort devoted to reporting beyond what they need internally
Target end-state
Impediments
Re
ad
y
Do
ne
L
© 2
013 S
cru
m I
nc.
Automatic Reporting Via Scrum Tools
Backlog Tool
$
Financial Data Happiness Tool
API connec4on
1. Tap into data the team
should already collect to
manage their process
2. Pull and aggregate it
automa3cally
• API interfaces • “The Cloud”
3. Make it available to
everyone to drive radical
transparency
• Minimizes wasted effort
genera4ng repor4ng
• Team gets clear feedback
• Leadership gets required visibility
• Crea4ve solu4ons to “make work
visible” welcome!
• No addi4onal
work
Informa4on “Radiator”
© 2
013 S
cru
m I
nc.
Five-Metric Dashboard to Track Progress
1. Release Burndown chart • Will we finish as expected?
2. Acceleration – Velocity over time • How much are we producing?
3. Business value per point • Are we producing the right things?
4. Happiness metric • Are we doing it sustainably?
5. Process efficiency • Deep dive on specific issues
Sprint
Velocity
(points)
Quarter
Rev $/
point
Sprint
Happiness
ra4ng Role Company
Step 1 Step 2 Step 3 Step 4 Queue
5 20
2 10
60
3 17
6 30
+ + + + = 16 137
(12%)
Sprint
Release
Backlog
(points)
400
© 2
013 S
cru
m I
nc.
Leaders Prefer to Hide Dysfunction Rather than Fix It
• Stagnant or decreasing velocity for multiple Sprints
• Sprints often failed or extended
• A decreasing or continuously low team morale • Tendency to assign responsibility for failure
• Grumbling that things were better before Scrum
Typical symptoms
• Stagnant velocity and failing sprints • The team routinely encounters impediments it
is not able to remove alone
• SM unable to find a leader to champion impediment removal
• Identified impediments perceived as threat rather than opportunity
• Culture of blame not solution-seeking
• Low team morale • Organizational focus on finding fault rather than
finding solution • Culture of blame not solution-seeking
Root causes
Transform Culture • Embrace learning from failure over assigning
blame
• Change incentive structures that punish setbacks • Build trust through transparency and actively
addressing impediments in a constructive manner
Manage the “Change Curve” • Get leadership coaching and training on how to
lead organizational change • Be mindful of “soft” as well as “hard” project
management skills in delivering project success
What to do about it
• Teams willing to take appropriate risks to pursue great results
• Teams and leadership work together to remove
impediments rapidly • Conversations around key issues have neutral
tone and more action-oriented • Velocity trends upwards at ~10% per Sprint • Teams celebrate success
Target end-state
Impediments
Re
ad
y
Do
ne
L
© 2
013 S
cru
m I
nc.
A Note on Radical Transparency
19
“Hidden Treasures” “Core
Competencies”
“Blind Spots” “Opportuni4es for
Development”
Strength
Weakness
Unknown Known Awareness
Competence
Ini4ally, it may feel like Scrum is making things
worse, but this is actually part of geong beBer
© 2
013 S
cru
m I
nc.
Managing The Emotional Side of Change
Source: Duck, Jeannie: “The Change Monster”
Time
Morale and
Confidence
Phase Stagna3on Prepara3on Implementa3on Determina3on Frui3on
• Organiza4on is
depressed,
lethargic or
unfocused
• Leaders engage
in planning and
communica4on
• Appe4te for
change reaches
cri4cal mass
• Ini4a4ves roll out,
impac4ng more of
the organiza4on
• Early successes
build confidence
• Conflicts and
clashes result from
differences in vision
• Emo4ons swing
drama4cally with
each minor success
or failure
• Change is either
abandoned or the
organiza4on
perseveres and
succeeds
A decision is
made to
change
First realiza4on that
something is “going wrong”
What it
looks like
Las4ng organiza4onal transforma4on requires mastering “The Change Curve”
20
© 2
013 S
cru
m I
nc.
Leadership Not Prioritizing Between Competing Directions
• A sense of “everything is a priority.” • The backlog is ordered to deliver multiple project
simultaneously, with no clear prioritization.
• Individual functionality rarely gets to done, but is rather a WIP.
• Poor continuity of goals/focus from Sprint to Sprint. Team feels as if it is asked to shift focus continuously
Typical symptoms
• Everything is a priority • Leadership is not presenting a clear
vision
• Backlog attempts to deliver multiple project • The PO has not ordered the backlog with a
clear priority • The PO is not empowered
• Individual Functionality remains WIP
• Lack of direction on how to get Done • Poorly defined PO role
• Team is asked to shift focus often • PO does not have a clear sense of priority
• Leadership is not presenting a clear
vision
Root causes
Leadership does not present a clear vision • Organize a Meta Scrum, or meeting of the minds,
to decide on a clear vision for the organization.
Communicate this vision to the organization. • Establish and communicate the relative value of
the organization’s initiatives. This will empower PO to order their backlog in alignment with the organization’s leadership.
PO role is not empowered or well defined • Gather together the stakeholders and examine
the flow of information to the team. The PO should be the sole source of work and priority for the team. Develop an effective method for the
stakeholders to communicate their needs to the PO. The PO will then be able to provide the team with a well defined and ordered backlog.
What to do about it
• The vision and goals are clearly communicated to the entire organization.
• There is a single flow of backlog coming to the
team from the PO. • The PO is empowered to order the backlog in
alignment with the organization’s vision.
Target end-state
Impediments
Re
ad
y
Do
ne
L
© 2
013 S
cru
m I
nc.
The Meta Scrum: Used to Align Organizational Priorities
Impediments
Re
ad
y
Do
ne
L
Leadership
SH
Stakeholders
PO
Product Owners
Aligned Product Backlog
L
SH PO
Team
1
Team
2
Team
3
Sprint/Time
Aligned Product Backlog
L
PO Team
1
Team
2
Team
3
Aligned Product Backlog
L
PO
Team
1
Team
2
Team
3
• A gathering of key Stakeholders, Leadership,
and Product Owners
• Run by Chief Product
Owner
• The forum for stakeholders to express preferences
(they should not lobby
teams directly or try to
alter product vision
between Meta Scrums)
• Can be held at regular
intervals or on an ad-hoc
basis
• Allows teams to progress efficiently down a single
work path
SH SH
SH SH SH
SH SH SH
© 2
013 S
cru
m I
nc.
Product Owner is a Big Job
• Initially, one Product Owner may be able to generate ready backlog for several teams
• As team velocity increases, a Product Owner team, led by a Chief Product Owner, will be needed
• The Product Owner team are domain experts that describe the user experience, the screen shots, the workflow, the data requirements, the look and feel.
T T T T T T T T T
PO PO CPO
PO
T T T T T T T T T
© 2
013 S
cru
m I
nc.
Leadership Not Supporting Impediment Removal
• Significant team impediments have been identified, but remain in place after many sprints
• Small impediments are removed rapidly, but
broader over-arching ones remain • Team is becoming demoralized and starts to
accept large impediments as “as given” • Velocity has flat lined
Typical symptoms
• Velocity has flat lined and is not improving • One or more significant impediments exists and
has not been addressed
• While small internal impediments are removed quickly by SM, impediments beyond
team’s ability to address directly are not removed
• Leadership lacks visibility of larger
impediments • No mechanism for coordinating/
communicating larger impediments • Leadership not supporting removal of
impediments once they are aware
• Lack of clear responsibility/process for removing larger impediments
Root causes
No mechanism for coordinating/communicating larger impediments • Use Scrum of Scrums as a chance to compare
team impediments, identify ones that cut across teams, and prioritize major impediments
• Scrum Sponsor participates in highest level Scrum of Scrums, adds impediments to backlog
Lack of clear responsibility/process for removing larger impediments
• Identify clear Agile Sponsor and Transition Team responsible for eliminating major impediments
• Transition team works from its own backlog of prioritized impediments to remove
What to do about it
• Significant impediments surface and bubble up rapidly through the Scrum of Scrum’s process
• Transition team works its impediment backlog
effectively, with top priority impediment consistently removed within one week
• Team feels empowered to improve because issues they raise are addressed rapidly
• Team Velocity increases ~10% each Sprint
Target end-state
Impediments
Re
ad
y
Do
ne
L
© 2
013 S
cru
m I
nc.
How the Transition Team Works
Teams
Scrum of Scrums
Scrum of
Scrum of Scrums
Transi3on Team
Impediment Backlog
Iden4fied
impediments bubble
up through successive
Scrum of Scrums
If impediments cannot be
addressed at a lower level,
they are added to
Transi4on Team’s
Impediment backlog
IT Fin
HR
S
L
Sponsor and cross‐func4onal
Transi4on Team charged with
removing large impediments
and communica4ng back to
teams
Sponsor
HR
Finance Systems
Legal
Transi4on Team works
impediment backlog like a
development team works its
product backlog
1
2
3
4
✔✔
© 2
013 S
cru
m I
nc.
Conclusion
• We have reviewed an additional seven pitfalls we encounter frequently in the field
• If any of the symptoms above sound familiar, you may be experiencing one of these challenges now
• Conduct an A3 to flesh out root causes and align
organization around a plan of action
• We are always happy to help
• Removing Impediments and aligning Leadership
well should lead to at least a doubling of Velocity
© 2
013 S
cru
m I
nc.
Questions?
© 2
013 S
cru
m I
nc.
28
Stay Connected
Our Website • check in for announcements, new content and services, book
releases, and more!
• www.scruminc.com
ScrumLab • join the conversations on our forums with the scrum community
and your class. • coming soon: articles, videos, papers on all things scrum
• scrumlab.scruminc.com
Blog • scrum.jeffsutherland.com
Webinars • advance your learning with our interactive webinars. visit the
scrumlab store to view upcoming topics.
Twitter, Facebook, and G+
• @jeffsutherland, scrum and scrum inc.
top related