rise and downfall of a large scale scrum (less) implementation

source: http://goo.gl/cH6EwT

Michael ChikLean & Agile Coach for Startups & Enterprises

LEGO® SERIOUS PLAY® Facilitator

michael@arsagilis.com

@arsagilis

casmaron

linkedin.com/in/michaelchik

戚本錦 Previous:

Michael Chik is a Lean & Agile Coach with

over 15 years of experience in the software

industry. He is a CSP and AKT.

He started his Lean & Agile journey around 2001.

With a background in coaching, he strongly

believes in the human aspect of technology.

JP Morgan

Cathay Pacific

Fidelity International

Standard Chartered Bank

Walt Disney Company

Ben & Jerry’s

Photbox

Moonpig

Amnesty International

國際特赦組織

Multinational US-based Bank

3k+ people in Securities & Core

Processing

Started Large-Scale-Scrum

Implementation in 2013

Worked across 5 time zones

We did Scrum right!

For more info on LeSS, go to http://less.works

For more info on LeSS, go to http://less.works

© Tim Born

X X X X X

Gradual change back to waterfall

1st signs in December 2014

More signs in Q1 2015

1st resignation in February 2015

L1 managers reinstated

L0.5 management layer installed

Flat > Team Leads > Team Lead Managers

Only small pockets of Water-Scrum/Kanban-Fall left

100% resource utilisation > most is busywork

A lot of rework

Exodus

Operated across 5 different time zones

No team was split across different locations

All teams co-located

Enabled high-bandwith communication

Built trust within teams quickly

Forming > Storming > Norming > Performing

Danger: Can foster Us vs Them mentality

Traditionally: Component Teams

Each team takes responsibility for implementing

complete feature

Drastically reduced time to production

Faster feedback loops

Teams took responsibility for their work

Danger: Teams stepped on each other’s toes

PO presented teams with problems instead of

solutions

Teams responsible for splitting epics

Teams responsible for getting details

Motivates individuals and teams

Danger: Extensive coaching of both PO and teams

needed

PO presented teams with problems instead of

solutions

Teams responsible for splitting epics

Teams responsible for getting details

Motivates individuals and teams

Danger: Extensive coaching of both PO and teams

needed

Strong focus of Scrum Masters as coaches

Giving people mandate/tools to help themselves

Mentoring programme

Individuals felt that organisation/system cared

about them

High morale

Work was fun!

Morale was high

Drastically reduced time to production

2 releases/week instead of every 6 months

High quality

Teams felt like teams, despite scale

Sense of responsibility

Constraints: Domain, technical and functional

skills

People chose people they knew

Low diversity

Component-silos mostly remained

Teams need more constraints

Prevalent & popular idea in literature

Teams worked on what they wanted

Knew it was wrong – played the system and hid

Inter-team competition led to sabotage

DON’T: Absolute control > freedom

Give teams enough constraints

Loosen constraints over time to ease them into

self-organisation

Turned line mangers into coaches

One overarching coach per location

Middle & Senior management only pretended to support

but never believed

Hid inaction behind self-organisation

Management needs to realise they are in it for the

long-term

Clear roles & responsibilities needed

Prevalent idea in the agile literature

Requires certain degree of cultural maturity

Surrounding environment (eg bonus system) needs

to be aligned

Teams need constraints > adjust them according to their

level of maturity

Gradually introduce them to self-organisation

Great idea (in theory)

Some “bad” developers became Scrum

Masters

Teams didn’t treat SMs differently

Teams shied away from giving critical

feedback

Teams never fired a SM

Popularity contest vs attitude & skills

We followed the Boy Scout Principle

Impossible to enfore

Only works if everyone follows it

Defunct code left in codebase

Broken tests > disabled

Have a technical coach in place

Great idea (in theory)

Impossible to enforce

Only works if everyone follows it

DON’T: When teams compete against

each other

The more you grow, the fatter you get

Never let growth be the goal

De-scaling instead of scaling

Scale with fewer teams

In a relentless pursuit of growth,

Toyota dropped the ball and […] quality

ultimately suffered as a result.

“”

改革

Kaikaku = Revolutionary Change

Scaling with big changes overwhelms

people

LeSS Huge recommends incremental

approach

Have a bunch of good coaches ready

Limit change in progress

Scrum Team = everyone is a programmer

No QAs or BAs

Cross-functional = willing to do more than just

your specialty

Actively integrate BAs and QAs into your team!

Operated over 5 time zones

Biggest time difference: 12h

Dramatically slows down decision making

LeSS: Requirement Areas

DON’T: Spawn RAs over more than 4h difference

Share the pain

Ask: Is this sustainable?

Depends on organisational culture

Heavily influenced by environmental factors

(eg bonus systems, HR, etc)

May only be overridden by a strong team culture

DON’T: Scale when organisation still plays the

contract game

Romanesco broccoli

PUZZLED?QUESTIONS?COMMENTS?

michael@arsagilis.com

@arsagilis

casmaron

linkedin.com/in/michaelchik