Liberating your Teams from Rigid Scope and Date Agreements.pdf

@rowanb
with Rowan Bunning CST
Liberating Your Teams
from Rigid Scope and
Date Agreements

© 2023 Rowan Bunning, Scrum WithStyle scrumwithstyle.com
About Rowan Bunning
• 25+ year involvement in software and product
development.
• Background in O.O. & web dev. with vendors, enterprise
product development, start-ups & consultancies
• Started Agile journey in 2001 (eXtreme Programming)
• Australia’s
fi
rst Scrum Master - 2003
• Introduced Scrum+XP organisation-wide
• Co-founder and Product Manager at a software startup
• Agile Coach at Ken Schwaber’s European partner in 2008
• Have delivered >500 certi
fi
cation courses on Scrum
• Management consultant on Agile adoption choices
• Organiser of Regional Scrum Gatherings®
• Married with a toddler and spoodle.
2005
2006
2008
2018
2017
2015
2010

@rowanb
Agenda
Part A: The Contract Game
Part B: Contract Game elimination techniques
Craig Larman
Bas Vodde
Many thanks to

© 2015 Scrum WithStyle scrumwithstyle.com
This includes scope
& date agreements
internally.

External contracts spawn internal contracts
Business
External
customers
Development
External
contract
Internal
contract

The Contract Game players
Product
Management
R&D
start end
(release)
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.
Business Development

Negotiated scope and date
Product
Management
R&D
start end
(release)
content freeze
(release contract agreed)
The Milestone point is arbitrary
The Contract
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
Business
Date & Scope
sign-off
Development

Handoff of responsibility
Product
Management
R&D
start end
(release)
content freeze
The Contract
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
Date & Scope
commitment
Responsibility
low control
low
fl
exibility
low transparency
big batches
cannot release early
not “done” until the end
Business
have
completed
date and
scope move
Development

@rowanb
Over to Development
Product
Management
R&D
start end
(release)
content freeze
* Development Phase for The Contract is controlled by R&D.
* The order of work is decided by R&D.
* Product Management does not have control, and there is low
visibility into the status of true progress.
The Contract
ineffective bonus schemes and "tracking
to plan" behaviors are injected, since
there is no real control or visibility
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
Business
• Development Phase for The Contract is controlled by the development group
• The order of work is decided by the development group
• The Business does not have control, and there is low visibility into the true
status of progress.
Development

Incentives & hierarchy encourage opacity
Business stakeholders
“Everything is going really well.”
Program manager
“Things are basically on track, we’re
doing some minor risk management
to head off issues arising.”
Second level manager
“Things are kind of rough but
we’re managing the problems.”
First level manager
Developer
“It’s a big mess. I have no idea
how we’re going to get this done.”

Opacity

Product
Management
R&D
start end
(release)
content freeze
more,
more,
more!
1
The Milestone point
is arbitrary
The Contract
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
Business Development

Product
Management
R&D
start end
(release)
content freeze
The Milestone point
is arbitrary
more,
more,
more!
less,
less,
less!
1 2
The Contract
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
Business
The date and scope contract
point represents the time that
both parties have maximised the
ability to shift blame when
something goes wrong.
Development

Words don’t eliminate intrinsic variability
Product
Management
R&D
start end
(release)
content freeze
The Contract
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
Business
There’s been a
surprise!
But you
committed!
Development
Getting near
the “end”

We blame the other party
your fault
your fault
Product
Management
R&D
start end
(release)
your fault your fault
The Contract
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
Business I.T.
Development

@rowanb
Now development pulls out the ‘Secret Toolbox’
• Overtime
• No longer thinking about the design
• Poor quality code
• No longer taking time to learn
• Stopping testing
• Poor quality product
• Not
fi
xing weakness in organisation

@rowanb
Long term consequences of
The Contract Game
• Attrition of the best people
• Lots of technical debt
• Increased Total Cost of
Ownership
• Rewrite
• Distrust
• Outsourcing of the problem

Secret toolbox dynamics
Goal: conform to
original schedule
actual
variance to
original
schedule
pressure to try
actions to
conform to
original schedule
QF
QF
% use of “secret
toolbox”— hacking to
generate bad code
quickly
exhortations,
bribes, and threats
to developers to
meet schedule
duration and
effort to add
new features
O
the key dynamic under
discussion: short-term
improvement but long-
term degradation of the
same variable
long
term
short
term
management belief:
exhortations,
bribes, and threats
make things faster
management belief:
estimates are not estimates,
but commitments
management belief:
managers should not be
looking at the code
www.craiglarman.com
www.odd-e.com
Copyright © 2009
C.Larman & B. Vodde

Agile is meant to be a cooperative game

Part B: Contract Game
elimination techniques

@rowanb
Contract Game elimination techniques
1. Educate about The Contract Game
2. Educate about product development
3. Make releases more frequent
4. Focus on impacts, not outputs
5. Shift from timelines to trends
6. Move the Product Owner role to the external contract owner
7. Separate development from external commitments
8. Remove project management
9. Expand the product de
fi
nition
10. Restructure to Feature Teams
11. Adopt LeSS

Educate about
The Contract Game
Ingredient 1

@rowanb
Step 1 is Awareness
• Awareness can make a big difference
• Use this talk!
• Use keynotes by Craig Larman
e.g. Keynote (Ericsson) - Scaling Agile with Large-
Scale Scrum - Craig Larman: youtu.be/
Gw1lLt18KzE?t=1259
• Practices for Scaling Lean and Agile Development
by Craig Larman and Bas Vodde - Chapter 4:
Product Management

@rowanb
Game changing questions
A. Do key stakeholders believe that the optimal product
content and design is unknowable early in
development?
B. Are key stakeholders aware of how they can steer
throughout development to maximise the bene
fi
ts for
their spend? ?

Technique 2
Educate about
Product Development

@rowanb
Which do stakeholder believe we’re doing?
or
Building
Learning

@rowanb
Estimates are not Commitments

@rowanb
Expecting Fixed or Evolutionary?
Fixed Incremental delivery
In 'pure' incremental delivery, "a plan is de
fi
ned of several future deliveries -
feedback is not driving the delivery plan."
Evolutionary delivery
"Evolutionary delivery is a re
fi
nement of the practice of incremental delivery
in which there is a vigorous attempt to capture feedback regarding the
installed product, and use this to guide the next delivery. In evolutionary
delivery, there is no plan (or at least no
fi
xed plan) of future deliveries; each
is dynamically created based on emerging information."
Larman, C. (2012). Agile and iterative development : a manager’s guide. Boston: Addison-Wesley, Cop.
Excerpt: https://www.informit.com/articles/article.aspx?p=102256&seqNum=10

@rowanb
A. Do managers and stakeholders think of product development
more like construction of a building or the design of a novel
structure?
B. Do managers and stakeholders believe that Scrum / Agile is for
delivery teams only or that it is most bene
fi
cial when product
management and/or stakeholders substantially change their
approach as well?
C. Which are we more interested in:
• delivering what was a agreed on time and on budget but not
realising bene
fi
ts suf
fi
cient to make it worthwhile, or
• discovering the right formulation of product and how to create
and sustain it to achieve a high ROI?
?

Technique 3
Make releases more
frequent

@rowanb
© 2017-8 Scrum WithStyle scrumwithstyle.com
Release more frequently that people change their mind!
Batch 1 Batch 2 Batch 3 Batch 4 Batch 5 Batch 6 Batch 7 Batch 8 Batch 9 Batch 10
Batch 1
Batch 1 Batch 2
Batch 1
Batch 2 Batch 3 Batch 4 Batch 5
Time
Pressure
to change
scope

@rowanb
A. How frequently do we need to release to avoid the need
for multi-Sprint scope agreements?
?

Technique 4
Focus on impacts,
not outputs

@rowanb
Contract Game smell: Gantt chart
Source: smartsheet.com/content/agile-gantt

@rowanb
Contract Game smell: Product Roadmap
Source: idalko.com/jira-roadmaps/

@rowanb
Focus on Product Goal over Outputs
Product goal
• Measurable
• Ideally impact (ROI)
• Output
fl
exible
• Timing forecast regularly
updated
See: https://medium.com/serious-scrum/how-to-craft-a-product-goal-70802b761caa

@rowanb
Make your Roadmap Goal Oriented

@rowanb
Use a Product Goal progress meter
5%
10%
20%
15%
Product Goal: increase trial customers converting
to paid subscribers by 20% within 4 months.

@rowanb
A. Do we want to maximise output or produce the desired
impacts with the minimum output?
B. How can we make measurable outcomes and impacts
suf
fi
cient visibile to be of more importance than outputs?
?

Technique 5
Shift from timelines
to trends

@rowanb
Make your Product Backlog understood
• Understood by those
interested
"The Product Owner is
accountable for...
Ensuring that the Product
Backlog is transparent,
visible and understood.”
- The Scrum Guide (2020)

@rowanb
Stakeholder: “When is this going to be delivered?”
Product Owner: “Let’s have a look at where it is
in the queue. Also what current trends suggest.”
Responding to stakeholders

@rowanb
Forecast it, don't
fi
x it
Source: blogs.ripple-rock.com/colinbird/2017/01/04/HasTheBurndownChartBurntout.aspx

@rowanb
A. What will it take for the Product Backlog to be suf
fi
ciently
transparent to stakeholder that they don’t require a time-
based plan?
B. What will it take to shift the conversation from how much
we have delivered, to how the product is shaping up?
C. What will it take to be con
fi
dent enough to let
requirements emerge as we go?
?

Technique 6
Move the Product Owner role
to the external contract owner

External contracts spawn internal contracts
Business
External
customers
Development
External
contract
Internal
contract
Who is this person?

@rowanb
Product Owner steers
Product
Owner steers
External
customers
Teams
External
demand
✘ No Scope and Date contract
✔︎
Business steers directly
☸
PO
📖
Governed by the
Rules of Scrum

@rowanb
With good Scrum…
• Contracts between the Business and Development are
eliminated.
• Instead, there is a Product Owner from the business.
• The “more, more, more” person with the external contract /
business pro
fi
tability problem is given the steering wheel.
• The Product Owner can change the content and date of
release each Sprint.

@rowanb
A. Who in the organisation owns the external contract
problem for our product?
B. What can we do to engage that person as Product
Owner? ?

Technique 7
Separate development from
external commitments

@rowanb
Sustainable pace without pressure from
external commitments
“You assume that you are developing the
fastest when doing it sustainably and thus
ignoring commitments made.”
- Bas Vodde

@rowanb
Shield teams from external commitments
Product Owner
External
customers
Teams
External
demand
PO
shields teams from
external and date
pressure
work at sustainable pace

@rowanb
A. How sustainable is this (perceived pressure / pace /
technical debt etc.)?
B. What could we do to make it more sustainable?
?

Technique 8
Remove project
management

@rowanb
Development
Before adopting Scrum
Business
Stakeholders
Project / Program
Management
Business Analysis
team
Architecture team
Development team
Testing team
Functional teams
Business

@rowanb
Development
After adopting Scrum
Implications:
• Program / development management are no longer
responsible for hitting release dates or milestones.
• Business representative steers directly.
Direct collaboration
Cross-functional
teams
Business
facilitated
by…

@rowanb
A. Do we believe that simplifying the organisation
contributes to transparency and agility / adaptiveness?
B. Are we prepared to focus on long lived products rather
than short lived projects?
?

Technique 9
Expand the product
definition

@rowanb
Dependency with other functional groups
• Need: co-ordinate dependent groups to achieve a substantial outcome.
• Try… bringing the skills of the dependent groups into the cross-functional
teams.
change
management
specialist
legal specialist
• Try… broadening the product de
fi
nition toward the full customer problem.

Rowan Bunning @rowanb
Avoid narrow “fake” products
Team 1 Team 2 Team 3 Team 4 Team 5 Team 6 Team 7 Team 8
.
.
.
gap
Overall priorities
Senior leader
End customers/users Other stakeholders
?
! !
Quoting
Leads and
Opportunities
Premium
calculation
iOS app CRM
Data
warehouse
Android app
PMO / Tribe

Rowan Bunning @rowanb
Try… single Product, Product Backlog, Product Owner
Team 1 Team 2 Team 3 Team 4 Team 5 Team 6 Team 7 Team 8
Overall priorities
Product Owner
End customers/users Other stakeholders
Product solving
customer problem

@rowanb
No pipelining
iteration 1 iteration 2
Scrum team
iteration 3
analysts,
architects,
interaction designers,
system engineers
iteration 1 iteration 2 iteration 3
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde

@rowanb
A. Who outside the Agile teams needs to co-ordinate
based on what we have when?
B. What would it take to have them or their skills within the
cross-functional teams?
?

Technique 10
Feature Teams

@rowanb
Contract Game smell: PI Commitments

@rowanb
Avoid… the inter-team Contract Game
Tigers
UX Help
Bears
Lions Unicorns Stakeholders
We expect them to keep on track
to deliver by these milestones
Single-function team
Component team
Component team
Component team
Component team

@rowanb
Feature Teams avoid planning time dependency
Item 1
Item 2
Item 3
Item 4
...
…
system
comp
C
Team
comp
A
Work from multiple teams is required
to finish a customer-centric feature.
These dependencies cause waste
such as additional planning and
coordination work, hand-offs
between teams, and delivery of
low-value items.
Work scope is narrow.
Product
Owner
comp
B
Team
comp
A
Team
comp
B
comp
C
Item 1
Item 2
Item 3
Item 4
...
…
Team
Wu
Product
Owner
Team
Shu
Team
Wei
system
comp
A
comp
B
comp
C
Every team completes customer-
centric items. The dependencies
between teams are related to shared
code. This simplifies planning but
causes a need for frequent
integration, modern engineering
practices, and additional learning.
Work scope is broad.
Component teams Feature teams
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde

Adopt LeSS

@rowanb
LeSS…
• aims to eliminate The Contract Game
• involves all of the previous techniques
• is partially described at less.works

@rowanb
Recommended References
• Cockburn, A., 2006, Agile Software Development: The
Cooperative Game, Second Edition, Addison-Wesley
Professional.
• Larman, C & Vodde, B, 2010, Practices for Scaling Lean and
Agile Development: Large, Multisite, and Offshore Product
Development with Large-Scale Scrum, Pearson Education,
Limited, Hoboken.
Chapter 4: Product Management
• Mezick, D., 2012, The culture game : tools for the agile manager.
North Haven, Conn.: New Technology Solutions, Inc.

@rowanb
The traditional Contract Game…
• Incentivises following a plan rather responding to change.
• creates an illusion of predictability and control that is misleading.
• leads to:
• low agility
• reduction in transparency and control
• reduced morale of team members
• increased total cost of ownership
• reduced trust

@rowanb
You can change the game!
• You will need to escape The Contract Game in order to fully realise the Agile promise
• There are many techniques:
1. Educate about The Contract Game
2. Educate about product development
3. Make releases more frequent
4. Eliminate content & date contracts
5. Move the Product Owner role to the external contract owner
6. Separate development from external commitments
7. Remove project management
8. Expand the product de
fi
nition
9. Restructure to Feature Teams
10. Adopt LeSS Upper by Pixabay. Lower photo by Quino Al on Unsplash

© 2023 Rowan Bunning, Scrum WithStyle scrumwithstyle.com
@rowanb au.linkedin.com/in/rowanbunning
Rowan Bunning
rowan@scrumwithstyle.com scrumwithstyle.com

Liberating your Teams from Rigid Scope and Date Agreements.pdf

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Liberating your Teams from Rigid Scope and Date Agreements.pdf

Similar to Liberating your Teams from Rigid Scope and Date Agreements.pdf (20)

More from Rowan Bunning

More from Rowan Bunning (14)

Recently uploaded

Recently uploaded (20)

Liberating your Teams from Rigid Scope and Date Agreements.pdf