rise and downfall of a large scale scrum (less) implementation
TRANSCRIPT
source: http://goo.gl/cH6EwT
Michael ChikLean & Agile Coach for Startups & Enterprises
LEGO® SERIOUS PLAY® Facilitator
@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?
