scaling! oh the horror!
DESCRIPTION
Why to people want to scale their software delivery production and why can it be horrifying? Slide deck to accompany my LAST Conference talk at #LASTconfTRANSCRIPT
11 July 2014!Swinburne University, Melbourne
LAST Conference 2014
Headline sponsor
Gold sponsors
Academic supporter
Silver sponsors
Supporters
Organised by
lastconference.com #LASTconf
Scaling! - Oh the horror!
Alexandra Stokeswww.alexandrastokes.com@StokesXandra
Scaling
• Why do we want to scale?
• Why is it horrifying?
• 3 software development scaling case studies - it’s real life folks!
Why scale?
Is it human nature?!Is it greed?!Is it just bad math?
Audience scaling dilemma
If you were faced with this scenario, what would you do? !
A. Start new business from scratch, i.e. duplicate results duplicate costs.
B. Leverage current business knowledge for new business line, i.e. duplicate results without duplicating costs.
Scale what?
• Amount of people/teams?
• Amount of throughput/output?
Or actual performance?
bigger numbers do not stack up when you are building software products
Communication Contracts
• Smaller the team less communication contracts required
• Larger the team more communication contracts required
diagram taken from lunar tractor www.lunartractor.com
Contracts per team size - let’s do the math!
3 person team => Contracts = (3-1) + (2-1) + (1-1) = 3
5 person team => Contracts = 4 + 3 + 2 + 1 = 10
10 person team => Contracts = 9 + …… + 1 = 45
100 person team => Contracts = 99 + ….. + 1 = 4950
Adding 1 person to a [team size] team, adds [team size] contracts.
Adding 1 person to a 3 person team adds 3 more contracts.
Adding 1 person to a 100 person team adds 100 more contracts!
scary graph!
team%size%
#%contracts%
0%
500%
1000%
1500%
2000%
2500%
3000%
3500%
4000%
4500%
5000%
3% 4% 5%10%
20%30%
40%100%
team%size%
#%contracts%
Productivity of teams as they grow
Proportion of time spent in communication
• 3 person team = 2% of time
• 5 person team = 4% of time
• 10 person team = 10% of time
• 100 person team = 103% of their time….huh?!
Result
• Communication fractures and halts
• Cells of communication form
• Silo’d thinking prevails
• Competition between teams
• Opposing agendas
• Politics
No longer serving aligned goals
it depends
Does that mean we should never scale software delivery?
case studies
Insuranceline
• Software itself couldn’t scale
• Distrust of IT by Business
• Pressure to beef up delivery capacity - do more
• Great cultural values
• No software Vendors - woo hoo!
• approx. 45 people in software delivery
Success factors for scaling at Insuranceline
AIA
• Oppressed workers
• Rigid legacy systems
• Heavy PMO and governance = slow and costly delivery
• Many single point failures
• Distributed delivery teams
• Bad Vendor
• approx. 90 people in software delivery
Success Factors AIAParters
Auspost DDC
• New department inside a giant org
• Insatiable appetite for digital
• Heavy PMO and governance
• Desire to prove agile
• Slow hiring processes
• New leadership team
• Growing from 20 - 120 rapidly
Success factors DDC
Principles, Values and Culture
Build Cells `
What have we learned?
• Organisations desire scale, scaling what?
• Maths doesn’t stack up for large teams to be effective
• Success factors for when you have to scale
• Stay faithful to your principles; people & culture
• Use scaling techniques we know work
• Impress your first customer before scaling
• Create self sufficient cells of teams
Any Questions? Alexandra Stokeswww.alexandrastokes.com@StokesXandra