© 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.