More Agile and LeSS dysfunction - may 2015

© 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

http://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

http://equinox.co.nz

http://siriustechnology.com.au

http://suncorp.com.au


Our IT organisations have been optimising around Waterfall for years


Was your project / product organisation designed with this in mind?


How many of these principles is your organisation based on?

Image credit: less.works


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


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


A thought on Systems Thinking



• 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


Impossible

To deliver on something outside current capability, invest in expanding capability

Current capability

💰Managers


Quick Intro to LeSS



Experiments

Guides

Framework

LeSS is based on 10+ years of real-world experiments

Principles


Books

2008 2010 Sept 20151995 2003


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


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


One Sprint, One ‘Done’, Many Teams


LeSS Huge - multiple Requirement Areas


Water-Scrum-Fall



Is Agile being ‘contained’ within something quite different?

Image credit: andrejkoelewijn.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.


😞😃

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



Dependency Hell



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


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



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



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



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



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.


Release Rigidity



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


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


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


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


Reality > Abstractions


The Contract Game



External contracts spawn internal contracts

Business

External customers

I.T.

External contract

Internal contract


Product

Management

R&Dstart end

(release)

www.craiglarman.com

www.odd-e.com

Copyright © 2010

C.Larman & B. Vodde


Business I.T.


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


Business

Date & Scopesign-off

I.T.


Product

Management

R&Dstart end




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.


Product

Management

R&Dstart end



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

I.T.


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


Opacity


Incentives are around being ‘on plan’

….rather than responding to change



Product

Management

R&Dstart end



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 I.T.


Product

Management

R&Dstart end



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


Shifting blame

Product

Management

R&Dstart end




The Contract

www.craiglarman.com

www.odd-e.com

Copyright © 2010

C.Larman & B. Vodde


I.T. Business

There’s been a surprise!

But you committed!


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


Business I.T.


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


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



Internal contracts create a competitive game

Consequences:

• Distrust.

• Increased technical debt.

• Rewrite

• Increased improvement debt.

• Outsourcing of the problem.


Agile is meant to be a cooperative game



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


I.T.Before adopting LeSS

BusinessStakeholders

Program Management

Business Analysis team

Architecture team

Development team

Testing team

Functional teamsBusiness


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…


Reality > Abstractions


Skills Bottlenecks



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.


Lack of Cross-team Learning



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


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



Lack of Design and Architectural Alignment



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



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


Collaborative modelling over specification

Image credit: less.works


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


Learn more about LeSS at less.works


@rowanb au.linkedin.com/in/rowanbunning

Rowan [email protected] scrumwithstyle.com

Than

k yo

u!Keep in touch

mailto:[email protected]

Leadership & Management

More Agile and LeSS dysfunction - may 2015