Date post: | 28-Jul-2015 |
Category: |
Leadership & Management |
Upload: | rowan-bunning |
View: | 366 times |
Download: | 0 times |
© 2015 Scrum WithStyle scrumwithstyle.com
Overcome common Agile problems by using Large-Scale Scrum (LeSS)
Real-world scaling problems and solutions from Large-Scale Scrum May, July 2015
with Rowan Bunning, CST
© 2015 Scrum WithStyle scrumwithstyle.com
Credit: This slide deck includes diagrams that are © C. Larman and B. Vodde. Thanks to Craig and Bas for sharing these and other diagrams at less.works
This material or a variation of this was presented at:
• May 7 at Project Management Institute (PMI) Sydney, Sydney Australia
• May 19 at Agile @ Scale meetup, Sydney Australia
• July 1 at Equinox IT webinar. View the recording at: equinox.co.nz/resources
Thanks to the following event sponsors
Equinox IT equinox.co.nz
Sirius Technology siriustechnology.com.au
Suncorp suncorp.com.au
© 2015 Scrum WithStyle scrumwithstyle.com
Our IT organisations have been optimising around Waterfall for years
© 2015 Scrum WithStyle scrumwithstyle.com
Was your project / product organisation designed with this in mind?
© 2015 Scrum WithStyle scrumwithstyle.com
How many of these principles is your organisation based on?
Image credit: less.works
© 2015 Scrum WithStyle scrumwithstyle.com
Q: What challenges are there?A: Organisational design flaws (in comparison to Agile and Lean principles)
The organisation was not designed with Agile and Lean principles in mind.
Traditional organisations become more complicated over time.
Large product development groups typically feature… • Functional groups • Big batches • Sequential processes • Weak feedback loops • Lots of handoffs
© 2015 Scrum WithStyle scrumwithstyle.com
Session Outline• Why is Agility at scale difficult?
• A thought on Systems Thinking
• Quick Intro to LeSS
• Water-Scrum-Fall
• Dependency Hell
• Release Rigidity
• The Contract Game
• Lack of Cross-team Learning
• Lack of Design and Architectural Alignment
© 2015 Scrum WithStyle scrumwithstyle.com
• A given system has finite performance characteristics • Your organisation is optimised to produce the results is currently produces • To produce different results, you need to change the system
To get from Wellington to Palmerston North… To get from Wellington to Sydney…
Systems Thinking
© 2015 Scrum WithStyle scrumwithstyle.com
Impossible
To deliver on something outside current capability, invest in expanding capability
Current capability
💰Managers
© 2015 Scrum WithStyle scrumwithstyle.com
Experiments
Guides
Framework
LeSS is based on 10+ years of real-world experiments
Principles
© 2015 Scrum WithStyle scrumwithstyle.com
Books
2008 2010 Sept 20151995 2003
© 2015 Scrum WithStyle scrumwithstyle.com
Traditionally, all of this becomes part of a ‘Program’
Business Product > IT Product
Business Producte.g. Transaction Banking
IT ‘Products’ (often systems or components)
Direct Entry system Domestic payments system
Collections system International payments
In LeSS, the customer-centric business product is ‘the product’ we focus on
© 2015 Scrum WithStyle scrumwithstyle.com
Large-Scale Scrum (LeSS) structure
PO
One Product Backlog
Task Task Task Task Task Task
Task Task Task Task
Task Task Task Task Task
Item #1 Item #2 Item #3
…
Up to about eight teams
One Sprint Backlog per Team
One dedicated ScrumMaster per
1-3 TeamsOne
Product Owner
© 2015 Scrum WithStyle scrumwithstyle.com
One Sprint, One ‘Done’, Many Teams
© 2015 Scrum WithStyle scrumwithstyle.com
LeSS Huge - multiple Requirement Areas
© 2015 Scrum WithStyle scrumwithstyle.com
Is Agile being ‘contained’ within something quite different?
Image credit: andrejkoelewijn.com
© 2015 Scrum WithStyle scrumwithstyle.com
😃😞
Water - Scrum - Fall💡 $
ArchitectsBusiness AnalystsProject Control Board
User Reps Operations
SIT UAT
System Testers
Deployment
Benefits Realisation begins
Envisioning
Big Batch Specification
Big Batch Project Scope
Product Backlog
Users
Released
2 weeks each SprintMany months Many months
Limited Coverage
Agile Team Programmers & Testers only
Dependent on other functional groups to get things specified or released. The other groups are
using a big-batch model.
© 2015 Scrum WithStyle scrumwithstyle.com
😞😃
Scrum
$
Flow of Value
Benefits Realisation begins
Vision & Business Goals
Product Backlog
Users
Feature Team that is fully cross-functional
2 weeks each Sprint
Released💡Feedback re Product and Process quality
OperationsSystem Testers
The Agile Team has the skills and authority to create Potentially Shippable
Product Increments each Sprint
ArchitectBusiness Analysts
Broadening of skills
© 2015 Scrum WithStyle scrumwithstyle.com
© 2015 Scrum WithStyle scrumwithstyle.com
Component teams lead to planning complexity
Item 1
Item 2
Item 3
...
Item 20
…
Item 42
current release:
need more people
next release:
need more people
System
next release
current release
Comp A
Team
Comp B
Team
Comp C
Team
Component
A
Component
B
Component
C
www.craiglarman.com
www.odd-e.com
Copyright © 2009
C.Larman & B. Vodde
All rights reserved.
© 2015 Scrum WithStyle scrumwithstyle.com Image credit: boost.co.nz
© 2015 Scrum WithStyle scrumwithstyle.com
Feature-teams are multi-component
Item 1
Item 2
Item 3
Item 4
…
…
Comp A
Team
Comp B
Team
Comp C
Team
Component
A
Component
B
Component
C
Product
Owner
Feature
Team
Red
tasks for A
tasks for B
tasks for A
tasks for B
tasks for A
tasks for C
contains ex-members
from component
teams A, B, and C,
and from analysis,
architecture, and
testing groups
system
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.
© 2015 Scrum WithStyle scrumwithstyle.com
Dependencies are pushed from planning to integration
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 oflow-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
All rights reserved.
© 2015 Scrum WithStyle scrumwithstyle.com
Co-ordination is in shared code
Item 1
Item 2
Item 3
...
Item 8
…
Item 12
Team
Wei
Team
Shu
Team
Wu
Component
A
Component
B
Component
C
With feature teams, teams can always work on the highest-value features, there is less delay for
delivering value, and coordination issues shift toward the shared code rather than coordination
through upfront planning, delayed work, and handoff. In the 1960s and 70s this code coordination
was awkward due to weak tools and practices. Modern open-source tools and practices such as
TDD and continuous integration make this coordination relatively simple.
system
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.
© 2015 Scrum WithStyle scrumwithstyle.com
Feature teams are customer-centric
Team has the necessary knowledge and skills to complete
an end-to-end customer-centric feature. If not, the team is
expected to learn or acquire the needed knowledge and skill.
Feature team:
- stable and long-lived
- cross-functional
- cross-component
customer-
centric
feature
potentially
shippable
product
increment
Product
Backlog
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.
© 2015 Scrum WithStyle scrumwithstyle.com
Traditional Component
Team
Feature Teams
Ideal state!
Problem
Whole System
Whole Product
Sub System
Component
File / Class
Nothing Code + Design and Unit Test
+ Analysis and System Test
+ Co-creation
Extended Component Teams Conflight in scope in the team leading to duplication or additional coordination work
Functional over specification
Degree of cross-functionality
Potential Technology work scope inside the team
Feature team adoption path
Source: C. Larman & B. Vodde.
© 2015 Scrum WithStyle scrumwithstyle.com
4 releases/year using release train and component teams
Month 11
Internal contract
2 3 5 74 6 8 9 10 121
Internal contract
Internal contract
Internal contract
Releas
e
Releas
e
Releas
e
Releas
e
© 2015 Scrum WithStyle scrumwithstyle.com
25 releases/year with Potentially Shippable Product Increments
Month 11
Internal contract
2 3 5 74 6 8 9 10 121
Internal contract
Internal contract
Internal contract
Releas
eRele
ase
Releas
eRele
ase
Releas
eRele
ase
Releas
eRele
ase
Releas
eRele
ase
Releas
eRele
ase
Releas
eRele
ase
Releas
eRele
ase
Releas
eRele
ase
Releas
eRele
ase
Releas
eRele
ase
Releas
eRele
ase
Releas
e
© 2015 Scrum WithStyle scrumwithstyle.com
Smaller releases earlier = increased benefits realised
$1M
$800K
$600K
$400K
$200K
Sprint 1 2 3 4 5 6 7 8 9 10 11 12 13Month 1 2 3 4 5 6
$1M
$800K
$600K
$400K
$200K
Sprint 1 2 3 4 5 6 7 8 9 10 11 12 13Month 1 2 3 4 5 6
© 2015 Scrum WithStyle scrumwithstyle.com
Potentially Shippable Product Increment every Sprint gives the business…
• early realisation of business value
• flexible decision about when/what to deploy
• flexible re-prioritisation each short cycle based on changes in business conditions, learning etc.
• improved quality and fitness for purpose
• improved estimates
• increased visibility of something meaningful
• early full-cycle feedback (documents don’t crash!)
• early learning
© 2015 Scrum WithStyle scrumwithstyle.com
Reality > Abstractions
© 2015 Scrum WithStyle scrumwithstyle.com
External contracts spawn internal contracts
Business
External customers
I.T.
External contract
Internal contract
© 2015 Scrum WithStyle scrumwithstyle.com
Product
Management
R&Dstart end
(release)
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.
Business I.T.
© 2015 Scrum WithStyle scrumwithstyle.com
Product
Management
R&Dstart 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
All rights reserved.
Business
Date & Scopesign-off
I.T.
© 2015 Scrum WithStyle scrumwithstyle.com
Product
Management
R&Dstart 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
All rights reserved.Date & Scopecommitment
Responsibility
low controllow flexibility
low transparencybig batches
cannot release earlynot “done” until the end
Businesshave
completed date and
scope move
I.T.
© 2015 Scrum WithStyle scrumwithstyle.com
Product
Management
R&Dstart end
(release)content freeze
(release contract agreed)
* 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
All rights reserved.
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.
I.T.
© 2015 Scrum WithStyle scrumwithstyle.com
Incentives & hierarchy encourage opacityBusiness 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.”
© 2015 Scrum WithStyle scrumwithstyle.com
Opacity
© 2015 Scrum WithStyle scrumwithstyle.com
Incentives are around being ‘on plan’
….rather than responding to change
© 2015 Scrum WithStyle scrumwithstyle.com
© 2015 Scrum WithStyle scrumwithstyle.com
Product
Management
R&Dstart end
(release)content freeze
(release contract agreed)
more,
more,
more!
1
The Milestone point
is arbitrary
The Contract
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.
Business I.T.
© 2015 Scrum WithStyle scrumwithstyle.com
Product
Management
R&Dstart end
(release)content freeze
(release contract agreed)
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
All rights reserved.
Business I.T.
The date and scope contract point represents the time that
both parties have maximised the ability to shift blame when something goes wrong.
© 2015 Scrum WithStyle scrumwithstyle.com
Shifting blame
Product
Management
R&Dstart 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
All rights reserved.
I.T. Business
There’s been a surprise!
But you committed!
© 2015 Scrum WithStyle scrumwithstyle.com
We have a two party competitive game
your faultyour fault
Product
Management
R&Dstart end
(release)
your fault your fault
The Contractwww.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.
Business I.T.
© 2015 Scrum WithStyle scrumwithstyle.com
Now development pulls out the ‘Secret Toolbox’
• Crappy code
• No longer thinking about the design
• No longer taking time to learn
• Stopping testing
• Not fixing weakness in organisation
• Overtime leading to attrition of the best people
© 2015 Scrum WithStyle scrumwithstyle.com
Secret toolbox dynamics
Goal: conform to
original schedule
actual
variance to
original
schedule
pressure to try
actions to
conform to
original schedule
QFQF
% 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 featuresO
the key dynamic under discussion: short-term improvement but long-term degradation of the same variable
longterm
shortterm
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
All rights reserved.
© 2015 Scrum WithStyle scrumwithstyle.com
Internal contracts create a competitive game
Consequences:
• Distrust.
• Increased technical debt.
• Rewrite
• Increased improvement debt.
• Outsourcing of the problem.
© 2015 Scrum WithStyle scrumwithstyle.com
Agile is meant to be a cooperative game
© 2015 Scrum WithStyle scrumwithstyle.com
© 2015 Scrum WithStyle scrumwithstyle.com
With good Scrum…• Contracts between the Business and I.T / Program
management are eliminated.
• Instead, there is a Product Owner from the business.
• The “more, more, more” person with the external contract / business profitability problem is given the steering wheel.
• The Product Owner can change the content and date of release at a fidelity of each Sprint.
• Product Owner typically Head of Business Line or Head of Product Management
© 2015 Scrum WithStyle scrumwithstyle.com
I.T.Before adopting LeSS
BusinessStakeholders
Program Management
Business Analysis team
Architecture team
Development team
Testing team
Functional teamsBusiness
© 2015 Scrum WithStyle scrumwithstyle.com
After adopting Less
Implications:
• Program / development management are no longer responsible for hitting release dates or milestones.
• Good Scrum involves elimination of the contract game.
Direct collaboration
Cross-functional teams
I.T.Business
facilitated by…
© 2015 Scrum WithStyle scrumwithstyle.com
Reality > Abstractions
© 2015 Scrum WithStyle scrumwithstyle.com
Team skills
E F G
Learning allows us to keep whole feature with single team
Product Backlog
D E Fskills required
Team skills
A B CA B Cskills required
Team skills
C D E
d
Will slow down as they learn a bit of d.
Principles: • Whenever we can use specialisation to maximum advantage, we use it. • Whenever specialisation becomes a constraint, we break the constraint. • Better to do a high value thing slower than a low value thing fast. •Expanding skills capability is valuable.
© 2015 Scrum WithStyle scrumwithstyle.com
Sprint Backlog
Product Owner
Product Backlog
2-4 week Sprint
Daily Scrum (15 min)
1 day
Sprint Retrospective
(1.5-3 h)
Sprint Planning
Part 2 (2-4 h)
+
+
+
(Feature) Team
+ ScrumMaster
Sprint Planning
Part 1 (2-4 h)
Joint Retrospective
(1.5 h)
ScrumMasters and one representative from each team meet early in next Sprint to deal
with systemic issues
Product Backlog Refinement (5-10% of Sprint)
Potentially Shippable Product Increment
Sprint Review
(2-4 h)
Using ‘science-fair’ style diverge - converge format
Product Backlog Refinement (5-10% of Sprint)
Big Room RefinementAll teams in one room with
own learning tools (whiteboards, projectors etc.)
© 2015 Scrum WithStyle scrumwithstyle.com
The regular teams do the Undone Release work
• This creates opportunities for cross-functional learning • May start with pairing specialist group with regular teams • Perfection vision: no release Sprint necessary
Undone
Work actual
release
Product Owner
wants to releaseRelease Sprint:
teams only do
Undone Work. . .
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.
© 2015 Scrum WithStyle scrumwithstyle.com
Lack of Design and Architectural Alignment
© 2015 Scrum WithStyle scrumwithstyle.com
Component teams lead to waterfall
Backlog Item 1
Backlog Item 2
...
Comp A
Team
Comp B
Team
Comp
C
Team
Analyst System
Engineer
System
Testers
Iteration 1 Iteration 2
(probably later)Iterations 3-5
(probably later
and more)
At least
iteration 6
(probably later)
Item 1
requirement
details
for Item 1
'backlog' by
component
not all teams start Item
1 at the same iteration;
they are multitasking
on multiple features system testers
cannot start
immediately on
Item 1; they are
multitasking on
multiple features
not available
until the analyst
is finished
Analysis
Design
Implementation
Test
Component teams lead to a sequential life cycle with handoff, queues, and
single-specialist groups and not true cross-functional teams without handoff.
code
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.
© 2015 Scrum WithStyle scrumwithstyle.com
2-4 week Sprint
Daily Scrum (15 min)
1 day
SAD workshop
Potentially
Joint Backlog Refinement
Team designDesign workshop at start of
each feature
Big room Backlog RefinementAll teams in one room with own
learning tools (whiteboards, projectors etc.)
Cross-team architectureJoint design workshop
initiated by Community of Practice facilitator
Shared understanding of existing architecture
Agile System Architecture Document (SAD) workshop
every few Sprints
Joint design workshop
Cross-team analysis and design
© 2015 Scrum WithStyle scrumwithstyle.com
Collaborative modelling over specification
Image credit: less.works
© 2015 Scrum WithStyle scrumwithstyle.com
What LeSS is not…• The ‘Contract Game’ which sets up win-lose dynamics between Business & Development • Continuing heavy dependency load and delay inherent with component teams • A relatively heavy method that needs to be tailored down to smaller groups (<50 ppl) • Scrum being ‘contained’ within something less adaptable • Requiring big batch Release Train planning with scope commitments made to executives • Product Owners from IT who are specifiers and not empowered to make commercial
decisions • Prioritisation by formula • Disallowing developers and stakeholders from collaborating at the same product review • Many roles with intermediated communication up and down hierarchies • Recommending part-time, temporary ScrumMasters • Limiting retrospectives to individual teams without overall cross-team retrospectives
© 2015 Scrum WithStyle scrumwithstyle.com
Learn more about LeSS at less.works
© 2015 Scrum WithStyle scrumwithstyle.com
@rowanb au.linkedin.com/in/rowanbunning
Rowan [email protected] scrumwithstyle.com
Than
k yo
u!Keep in touch