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 #LASTconf

1. 11 July 2014!
Swinburne University, Melbourne
LAST Conference 2014
Headline sponsor
Gold sponsors
Academic supporter
Silver sponsors
Supporters
Organised by
lastconference.com
#LASTconf

2. Scaling! - Oh the horror!
Alexandra Stokes
www.alexandrastokes.com
@StokesXandra

3. Scaling
• Why do we want to scale?
• Why is it horrifying?
• 3 software development scaling case studies - it’s real life
folks!

4. Why scale?
Is it human nature?
!
Is it greed?
!
Is it just bad math?

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

6. Scale what?
• Amount of people/teams?
• Amount of throughput/output?
Or actual performance?

8. bigger numbers do not stack up when you are
building software products

9. Communication
Contracts
• Smaller the team less
communication contracts
required
• Larger the team more
communication contracts
required
diagram taken from lunar tractor www.lunartractor.com

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

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

12. 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?!

13. Result
• Communication fractures and
halts
• Cells of communication form
• Silo’d thinking prevails
• Competition between teams
• Opposing agendas
• Politics
No longer serving aligned goals

14. it depends
Does that mean we should never scale
software delivery?

15. case studies

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

17. Success factors for scaling at Insuranceline

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

19. Success Factors AIA
Parters

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

21. Success factors DDC
Principles, Values and Culture

22. Build Cells `

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

24. Any Questions?
Alexandra Stokes
www.alexandrastokes.com
@StokesXandra