Scaling Agile 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

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

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

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

Scaling Agile Teams

Scaling Agile Teams

Recommended

More Related Content

What's hot

What's hot(20)

Similar to Scaling Agile Teams

Similar to Scaling Agile Teams(20)

Recently uploaded

Recently uploaded(20)

Scaling Agile Teams

Editor's Notes