More Agile and LeSS dysfunction - may 2015

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

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

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

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

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

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.

😞😃

Flow of Value

Benefits Realisation begins

Vision & Business Goals

Product Backlog

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

Comp B

Comp C

Component

www.craiglarman.com

www.odd-e.com

C.Larman & B. Vodde

Feature-teams are multi-component

Item 1

Item 2

Item 3

Item 4

Comp A

Comp B

Comp C

Component

Product

Feature

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

C.Larman & B. Vodde

Dependencies are pushed from planning to integration

Item 1

Item 2

Item 3

Item 4

system

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

Item 1

Item 2

Item 3

Item 4

…Team

Product

system

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

C.Larman & B. Vodde

Co-ordination is in shared code

Item 1

Item 2

Item 3

Item 8

Item 12

Component

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

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

C.Larman & B. Vodde

Traditional Component

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

Releas

25 releases/year with Potentially Shippable Product Increments

Month 11

Internal contract

2 3 5 74 6 8 9 10 121

Internal contract

Releas

Smaller releases earlier = increased benefits realised

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

External contract

Internal contract

Product

Management

R&Dstart end

(release)

www.craiglarman.com

www.odd-e.com

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

C.Larman & B. Vodde

Business

Date & Scopesign-off

Product

Management

R&Dstart end

The Contract

www.craiglarman.com

www.odd-e.com

C.Larman & B. Vodde

Responsibility

low controllow flexibility

low transparencybig batches

cannot release earlynot “done” until the end

Businesshave

completed date and

scope move

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

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.

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

The Milestone point

is arbitrary

The Contract

www.craiglarman.com

www.odd-e.com

C.Larman & B. Vodde

Business I.T.

Product

Management

R&Dstart end

The Milestone point

is arbitrary

The Contract

www.craiglarman.com

www.odd-e.com

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

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

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

% 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

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

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

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)

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

C.Larman & B. Vodde

Lack of Design and Architectural Alignment

Component teams lead to waterfall

Backlog Item 1

Backlog Item 2

Comp A

Comp B

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

Component teams lead to a sequential life cycle with handoff, queues, and

single-specialist groups and not true cross-functional teams without handoff.

www.craiglarman.com

www.odd-e.com

C.Larman & B. Vodde

2-4 week Sprint

Daily Scrum (15 min)

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 Bunningrowan@scrumwithstyle.com scrumwithstyle.com

u!Keep in touch

More Agile and LeSS dysfunction - may 2015

Leadership & Management

How to scale your Agile right - Arthur D. Little · (LeSS) methodology for several and complex streams or the sophisticated Scaled Agile Framework (SAFe) for whole organizations,

Christof EBERT - assets.vector.com · Large Scale Scrum (LeSS) Disciplined Agile Delivery (DAD) Agile for Critical Engineering (ACE) Scope SW, HW and Systems, ... Reuse strategies

Agile Lean LeadershipALL Elevator Pitch 191107 1 Agile Lean Leadership enables organizations, to generate more sustainable value for all stakeholders, The Road Less Travelled ALL Common

KAN MAN VARA AGIL UTAN ATT ANV NDA K NDA …...Scaled Agile Framework (Safe) Large Scale Scrum (Less) Agile Modern Agile Hearth of Agile Lean Kaizen Kata Beyond budgeting Test Driven

TMJ Dysfunction - cdn.ymaws.com · 18 Palpation Will require ... Patients with chronic TMJ dysfunction of a non-traumatic nature are less likely to progress quickly. Often, they are

Agile Sutra "Do more by doing less, Prevent rather than detect"

The Agile Factory - Applied Materialsmanufacturing typically focuses on producing more with less and being the low-cost supplier, agile manufacturing means being as responsive as possible

Menstrual dysfunction

Agile Market Research: More Insights in Less Time

Agile Designer™: HP ALM Less Test Cases, More Coverage Webinar

Agile at Scale · Introduction “Among the many aspects of Agile are the ability to move more ... Framework (SAFe), Large-Scale Scrum (LeSS), Nexus, and Disciplined Agile (DA) among

Personality Dysfunction

Now! Transformation! Stop your agile...Empowerment Delegation Kudos Practices Workouts Agile Scaling Frameworks LeSS, SAFe Holacracy Scrum@Scale Agile (Anti-)Transformation heutzutage

Pelvic floor dysfunction in the female: breaking the ... · dysfunction Defecatory dysfunction Pelvic floor dysfunction Bo K, Frawley HC, Haylen BT, et al. An International Urogynecological

Running head: HARMFUL DYSFUNCTION, MENTAL DISORDERS … ToK... · Harmful Dysfunction 1 . Running head: HARMFUL DYSFUNCTION, MENTAL DISORDERS AND DISEASE . The Harmful Dysfunction

Agile IT Delivery: Imperatives for Government Success · 7 AGILE IT DELIVERY: IMPERATIVES FOR GOVERNMENT SUCCESS #AGILEGOV ACHIEVE MORE FOR LESS States are turning to agile as an

Levels of Agile Planning - ASPE SDLC · ‣ The 5 Levels of Agile Planning ... manufacturing with less of everything? ... PRINCIPLE Parts Warehouse X 1,000,000’s

Agile Portfolio Management - Agility by delivering changes ... · Agile Portfolio Management ... If you want to transform your organization, ... (scaled Agile Framework) LeSS (huge)

Agile & DevOps : Gaming - HATech DevOps Services, a ... · “The DevOps movement addresses the dysfunction that results from organizations composed of functional silos. Thus, creating

Traditional vs. Agile Project Management · traditional model to the Agile model. ! In a business environment where the alignment between business and development strategies is less