This document discusses strategies for scaling agile teams as they grow in size. It begins by examining the ideal team size, noting recommendations ranging from 3-9 members. The key factor that determines team size is communication, as larger teams require exponentially more communication channels. The document then explores different strategies for splitting or structuring teams as they increase in number, including by component, feature, or hybrid approaches. It warns against both overly small "pods" that can become silos, as well as traditional component-split teams that result in high inter-team dependencies. Overall, the document advocates for cross-functional feature teams and recommends practices like onboarding, architectural guidance, and collaboration across distributed teams.

1. Scaling Agile Teams
Ron Lichty | Ron Lichty Consulting
Ron@RonLichty.com | www.ronlichty.com

2. * Addison Wesley (Amazon, BarnesandNoble, InformIT.com, Safari)
http://ManagingTheUnmanageable.net <-----tools, excerpts, more rules of thumb
© Ron Lichty 2
*

3. © Ron Lichty 3
http://ManagingTheUnmanageable.net <-----and pointers to video training

4. The Study of Product Team Performance
http://www.ronlichty.com/study.html
4© Ron Lichty

5. Ron Lichty,
Managing Software People & Teams
SOFTWEST

6. Untangling the Knots; Making Things Hum
• process
• culture
• communication
• planning
• rigor
© Ron Lichty 6

7. Software Development Organizations
Struggle with Structure
7
• Startups: When does our team become 2 teams?
• Larger orgs: Divide teams by components or by user function?
• Every org: As teams grow, when and how do we split them?
• Distributed teams: How do we distribute work geographically?
• Managers: What’s our role?
• Enterprises: Pools or teams?
• Teams: What is a team, anyway?
© Ron Lichty

8. A Couple Context Points for this Talk
8
The point is not to do Agile. The point is to
be effective. Agile provides us insights.
 --Al Shalloway, agile author/trainer/coach
Developing software is a team sport.
 --observation from 30 years managing programmers
© Ron Lichty

9. What’s the Ideal Team Size?
• Give me some answers in the chat window
© Ron Lichty 9

10. Ideal Team Size: Possible Answers
• Scrum (for 2 decades): 7 ± 2 (5 - 9)
• Scrum Guide today: 3 - 9
• Jeff Bezos: two-pizza rule (5 - 7)
• my coauthor, Mickey Mantle: 3 - 4
“a small team will usually outperform a larger team, hands down”
• my own answer?
© Ron Lichty 10

11. Ideal Team Size: Possible Answers
• Scrum (for 2 decades): 7 ± 2 (5 - 9)
• Scrum Guide today: 3 - 9
• Jeff Bezos: two-pizza rule (5 - 7)
• my coauthor, Mickey Mantle: 3 - 4
“a small team will usually outperform a larger team, hands down”
• my own answer (based on what gates teams): 1
© Ron Lichty 11

12. What Gates Teams: Communication
© Ron Lichty 12

13. What Gates Teams: Communication
© Ron Lichty 13

14. What Gates Teams: Communication
Lines of communication multiplicative
n(n-1)/2
© Ron Lichty 14

15. Ideal Team Size: 1
• all the communication is neuron-to-neuron
• J. Richard Hackman, Harvard: Team theory
“Research consistently shows that teams underperform...”
“problems with coordination and motivation typically chip away at
the benefits of collaboration”
• so what’s the issue?
© Ron Lichty 15

16. Ideal Team Size: 1
• all the communication is neuron-to-neuron
• J. Richard Hackman, Harvard: Team theory
“Research consistently shows that teams underperform...”
“problems with coordination and motivation typically chip away at
the benefits of collaboration”
• so what’s the issue?
• not many applications these days a single programmer can write
© Ron Lichty 16

17. Ideal Team Size: 1
• all the communication is neuron-to-neuron
• J. Richard Hackman, Harvard: Team theory
“Research consistently shows that teams underperform...”
“problems with coordination and motivation typically chip away at
the benefits of collaboration”
• so what’s the issue?
• not many applications these days a single programmer can write
• not many full-stack developers who can handle every part of an application
© Ron Lichty 17

18. Ideal Team Size: 3 - 4
• Mickey Mantle:
“a small team will usually outperform a larger team, hands down”
• Daniel Pupius, co-founder, Range:
“a sole genius isn’t going to solve problems in the way a group can”
• but even just Javascript: stacks of frameworks
MEAN - MongoDB - Express.js - AngularJS - Node.js
• ...and we run out of engineering bandwidth
© Ron Lichty 18

19. Ideal Team Size: two pizzas
• Jeff Bezos:
“5-7 people”
© Ron Lichty 19

20. Ideal Team Size: two pizzas
• Jeff Bezos:
“5-7 people, depending on their appetites”
© Ron Lichty 20

21. Scrum: 7 ± 2 or 3 - 9 (i.e., <10)
• J. Richard Hackman: Team theory
“Big teams usually wind up just wasting everybody’s time”
“My rule of thumb is no double digits”
• Mickey Mantle, Managing the Unmanageable:
“rarely have I seen productive teams that number more than a dozen”
• Ron Quartel, FAST-Agile creator
“a team of 14 that pairs would be the same as 7 channels of
communication with solo developers”
© Ron Lichty 21

22. Stable Teams
• J. Richard Hackman: Team theory
“R&D teams do need an influx of new talent to maintain creativity and
freshness—but only at the rate of one person every three to four years”
“The problem almost always is... that a team... doesn’t have the chance
to settle in... to learn through experience how best to operate as a team”
• Bruce Tuckman: Stages of Group Development
Forming / Storming / Norming / Performing
• Stability == estimating, velocity,
predictability
• (But Rich Sheridan, Joy, Inc., claims he’s overcome
teams-in-flux via XP practices, & has even beat Brooks Law!)© Ron Lichty 22

23. Splitting Growing Teams
• When and how do we divide a team > 9?
– Don’t: Keep the team intact
– Cell division
– Split the team
– Hybrid split
© Ron Lichty 23

24. Keep the Team Intact
• The “maximum of 9” is a guideline, not a law!
• But! recognize the communication burden
• Give focus to communication effectiveness
• Support Re-Forming / Storming / Norming / Performing
© Ron Lichty 24

25. Cell Division
• Cleave off a small team
© Ron Lichty 25

26. Cell Division
• Cleave off a small team
Steve Gray, Slalom: Find a smaller area of functionality
that a smaller part of the team can be spawned off to address
Daniel Pupius, co-founder, Range: Peel off a stable island
while the larger remaining group deals with the larger, less-
defined surface area
© Ron Lichty 26

27. Splitting Teams
• Give some thought to Conway’s Law
“Organizations which design systems... are constrained to
produce designs which are copies of the communication
structures of these organizations.”
Glyn Morrison’s variant: “Software development
organizations ship their organization chart.”
Eric Raymond’s variant: “If you have four groups
working on a compiler, you’ll get a 4-pass compiler.”
© Ron Lichty 27

28. Splitting Teams
• Give some thought to Conway’s Law
“Organizations which design systems... are constrained to
produce designs which are copies of the communication
structures of these organizations.”
Glyn Morrison’s variant: “Software development
organizations ship their organization chart.”
Eric Raymond’s variant: “If you have four groups
working on a compiler, you’ll get a 4-pass compiler.”
Al Shalloway’s variant: “When development groups
change how their development staff are organized, their
current application architecture will work against them.”
© Ron Lichty 28

29. How to Split the Team
• The easy route: splitting by components
– grouping like-minded, like-tooled,
common-best-practices people together
© Ron Lichty 29

30. Teams Split by Components
Web
Mgr
Database
Mgr
Server
Mgr
Network
Mgr
Systems
Mgr
t-shirts, public domain under Creative Commons CC0, https://pixabay.com/en/tee-shirt-white-clothing-casual-34009/
© Ron Lichty 30

31. Distributed Teams
Component-Split Geographically
flags, public domain under Creative Commons CC0, https://pixabay.com/en/sale-for-sale-pointer-pin-marker-1500944/
QA
Analytics
Biz Logic
Web Dev
DB
globe, public domain under Creative Commons CC0, https://pixabay.com/en/globe-world-map-earth-32299/
© Ron Lichty 31

32. How to Split the Team
• The easy route: splitting by components
– grouping like-minded, like-tooled,
common-best-practices people together
– easy management model
– teams each get an attuned manager/mentor/coach
• The problem:
– our goal: customer functionality, not components
– customer functionality requires multiple components
• incessant inter-team dependencies
• costly high-bandwidth, inter-team communication© Ron Lichty 32

33. How to Split the Team
• The easy route: splitting by components
– grouping like-minded, like-tooled,
common-best-practices people together
• The effective route: feature teams
– our goal: customer functionality, not components
– every team has every skillset needed to so deliver
© Ron Lichty 33

34. How Teams Change in Agile
Web
Mgr
DB
Mgr
Srvr
Mgr
Net
Mgr
Sys
Mgr
PjM
Mgr
PdM
Dir
Web
Mgr
DB
Mgr
Srvr
Mgr
Net
Mgr
Sys
Mgr
PMO
Mgr
PdM
Dir
PO PO PO PO PO
S
M
S
M
S
M
S
M
S
M
Team Team Team Team Team
From manager-led component teams… To self-organizing feature teams...
t-shirts, public domain under Creative Commons CC0, https://pixabay.com/en/tee-shirt-white-clothing-casual-34009/
© Ron Lichty 34

35. How Distributed Teams Change in Agile
From this…
flags, public domain under Creative Commons CC0, https://pixabay.com/en/sale-for-sale-pointer-pin-marker-1500944/
QA
Analytics
Biz Logic
Web Dev
DB
globe, public domain under Creative Commons CC0, https://pixabay.com/en/globe-world-map-earth-32299/
© Ron Lichty 35

36. To this…
How Distributed Teams Change in Agile
Feature
Team
Feature
Team
Feature
Team
Feature
Team
Feature
Team
flags, public domain under Creative Commons CC0, https://pixabay.com/en/sale-for-sale-pointer-pin-marker-1500944/
globe, public domain under Creative Commons CC0, https://pixabay.com/en/globe-world-map-earth-32299/
© Ron Lichty 36

37. How to Split the Team
• The easy route: splitting by components
– grouping like-minded, like-tooled,
common-best-practices people together
• The effective route: feature teams
– our goal: customer functionality, not components
– every team has every skillset needed to so deliver
• teams own interface, functionality, or customer journey
– same-skilled folks are scattered across teams
• each set still gets an attuned manager/mentor/coach
© Ron Lichty 37

38. How Teams Change in Agile
Web
Mgr
DB
Mgr
Srvr
Mgr
Net
Mgr
Sys
Mgr
PjM
Mgr
PdM
Dir
Web
Mgr
DB
Mgr
Srvr
Mgr
Net
Mgr
Sys
Mgr
PMO
Mgr
PdM
Dir
PO PO PO PO PO
S
M
S
M
S
M
S
M
S
M
Team Team Team Team Team
From manager-led component teams… To self-organizing feature teams...
t-shirts, public domain under Creative Commons CC0, https://pixabay.com/en/tee-shirt-white-clothing-casual-34009/
© Ron Lichty 38

39. Spotify calls its Scrum Teams “Squads”
• Each squad has a long-term mission, “owns” part of the UX
© Ron Lichty

40. Spotify: Kniberg calls Scrum Teams “Squads”
• Each squad has a long-term mission: e.g.,
building/improving the Android client, creating the Spotify
radio experience, scaling backend systems, payment
solutions, …

41. Managers lead “Chapters” that span Scrum
Teams
• “Chapters” are manager-led tech organizations
• Managers are called “Chapter Leads”

42. Splitting Teams: a second trap
• The easy route: splitting by components
– grouping like-minded, like-tooled,
common-best-practices people together
• The effective route: feature teams (or squads)
– each delivers customer functionality
• A second trap: tiny feature teams/squads/pods
– the problems:
• pods become silos
• high-bandwidth communication is needed among pods
© Ron Lichty 42

43. What Gates Teams: Communication
© Ron Lichty 43

44. Communication Gates Development
© Ron Lichty 44

45. Splitting Teams: a second trap
• The easy route: splitting by components
– grouping like-minded, like-tooled,
common-best-practices people together
• The effective route: feature teams (or squads)
– each delivers customer functionality
• A second trap: tiny feature teams/squads/pods
– the problems:
• pods become silos
• high-bandwidth communication is needed among pods
– with enough growth, it can be a trap for us all© Ron Lichty 45

46. Splitting Teams: a trap solution
• The easy route: splitting by components
– grouping like-minded, like-tooled,
common-best-practices people together
• The effective route: feature teams (or squads)
– each delivers customer functionality
• A second trap: tiny feature teams/squads/pods
– Spotify groups sets of squads into Tribes
– Zenefits groups sets of pods into Superpods
© Ron Lichty 46

47. Spotify groups sets of squads into Tribes

48. Hybrid Split
• Teams / Sub-teams hybrid model
– Startup with a team of 15 had been unproductive
– PdM ID’d 3 customer functionality workstreams
• but not long-running streams of features
– Split the team into 3 cross-functional sub-teams
• but stability was still at the larger team level
• and the code base was monolithic
– We did Planning, Demos and Retros by sub-team
– Standups, daily:
• first 11 minutes all together for sharing, dependencies
• then split up by sub-team for progress, 6 mins. planning© Ron Lichty

49. One More Model for Team Structuring
• FAST-Agile
– Organization of 40-plus
– Teams self-form every two days
• Around PdM’s 5 highest value initiatives
• Plan Tues/Thurs mornings
• Share outcomes Wed/Fri afternoons
© Ron Lichty 49

50. Regardless of Structure
• Make onboarding new team members a best practice
• Plan for architectural guidance across teams
• Fly geographically distributed teams together
• Plan cross-team, cross-geo, cross-tech hackathons
• Weekly all-hands show-and-tells have real value
– Leverage: align sprint reviews / demos with all-hands
• Remember Conway’s Law: You ship your organization!
• Make experiments of structure & process change
• Create a culture of psychological safety!
• Don’t just do agile, be agile!
© Ron Lichty 50

51. Team Structure Take-Aways
• Software development is a team sport
• There’s no one agile way to do things
• The point is to be effective / delight customers
• Organize teams to deliver customer value
• Cross-functional feature teams enable critical
communication / collaboration
• We’d stick with teams of 3 if we could
– But avoid cross-team communication overhead!
© Ron Lichty 51

52. Ron Lichty Consulting
• Software leadership, coaching, training, consulting:
– http://ronlichty.com, Ron@RonLichty.com
• The book:
Managing the Unmanageable:
Rules, Tools & Insights for Managing Software People & Teams
– http://ManagingTheUnmanageable.net <-----tools, excerpts, more rules of thumb
• The video training:
LiveLessons: Managing Software People and Teams
– http://ManagingTheUnmanageable.net/video.html
• The study:
The Study of Product Team Performance
– http://ronlichty.com/study.html
• Training:
The Agile Manager
Managing Software People and Teams
Zero to Agile in Three Days
52

53. Informit.com/lichty
Save 50% on Video Training
• Use code VIDEO50
Save 35% on Book
• Use code SWDEV35
• Good on print, eBooks, and video
• eBook files include PDF, EPUB, and MOBI
Discount codes applicable only at informit.com
Also available on the Safari Bookshelf

54. Ron Lichty Consulting
• Mentoring, coaching, training, consulting:
– http://ronlichty.com, Ron@RonLichty.com
• The book:
Managing the Unmanageable:
Rules, Tools & Insights for Managing Software People & Teams
– http://ManagingTheUnmanageable.net <-----tools, excerpts, more rules of thumb
• The video training:
LiveLessons: Managing Software People and Teams
– http://ManagingTheUnmanageable.net/video.html
• The study:
The Study of Product Team Performance
– http://ronlichty.com/study.html
• Training:
The Agile Manager
Managing Software People and Teams
Zero to Agile in Three Days
54

55. © Ron Lichty 55