Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Scaling Agile Teams

309 vues

Publié le

Ask any scrum coach about ideal team size and you’ll likely get the same answer: 7 plus or minus 2: that is, 5 to 9 team members doing the actual planning and work of the sprint.

But is that true?

And if it is, what do we do when we think we need to add a 10th team member to an already-maxed-out, 9-member team?

Splitting into two (or three!) teams seems fractious - siloing - so why would we cap teams at nine and split them at 10?

And what do we do when part of our team is local and part remote? Or when our entire team is scattered? How do we organize for best results?

Ron Lichty’s mantra is that software development is a team sport, which means that what gates productivity is communication. In this webinar, he’ll speak to organizing teams for effectiveness, productivity and joy.

Ron Lichty consults with software and product teams and organizations to make software development “hum”. Ron’s book, Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams (http://www.ManagingTheUnmanageable.net), published by Addison Wesley, has been compared by many readers to programming classics The Mythical Man-Month and Peopleware. His Live Lessons: Managing Software People and Teams video training for managers is available via O’Reilly’s Safari Bookshelf. Ron also co-authors the periodic Study of Product Team Performance (http://www.ronlichty.com/study.html).

Principal and owner of Ron Lichty Consulting, Inc. (www.RonLichty.com), he has trained teams in Scrum, transitioned teams from waterfall to agile, coached teams already using agile to make their software development "hum", and trained managers in managing software people and teams. He takes on interim VP Engineering roles and to other clients provides VPE-level guidance and advice to untangle the knots in software development and transform chaos to clarity.

He has led teams and organizations at companies like Apple Computer, Fujitsu, Charles Schwab, Avenue A / Razorfish, Forensic Logic, Stanford, Check Point, and dozens of startups of all sizes. He co-chairs the Silicon Valley Engineering Leadership Community.

Publié dans : Technologie
  • Soyez le premier à commenter

Scaling Agile Teams

  1. 1. Scaling Agile Teams Ron Lichty | Ron Lichty Consulting Ron@RonLichty.com | www.ronlichty.com
  2. 2. * Addison Wesley (Amazon, BarnesandNoble, InformIT.com, Safari) http://ManagingTheUnmanageable.net <-----tools, excerpts, more rules of thumb © Ron Lichty 2 *
  3. 3. © Ron Lichty 3 http://ManagingTheUnmanageable.net <-----and pointers to video training
  4. 4. The Study of Product Team Performance http://www.ronlichty.com/study.html 4© Ron Lichty
  5. 5. Ron Lichty, Managing Software People & Teams SOFTWEST
  6. 6. Untangling the Knots; Making Things Hum • process • culture • communication • planning • rigor © Ron Lichty 6
  7. 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. 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. 9. What’s the Ideal Team Size? • Give me some answers in the chat window © Ron Lichty 9
  10. 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. 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. 12. What Gates Teams: Communication © Ron Lichty 12
  13. 13. What Gates Teams: Communication © Ron Lichty 13
  14. 14. What Gates Teams: Communication Lines of communication multiplicative n(n-1)/2 © Ron Lichty 14
  15. 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. 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. 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. 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. 19. Ideal Team Size: two pizzas • Jeff Bezos: “5-7 people” © Ron Lichty 19
  20. 20. Ideal Team Size: two pizzas • Jeff Bezos: “5-7 people, depending on their appetites” © Ron Lichty 20
  21. 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. 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. 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. 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. 25. Cell Division • Cleave off a small team © Ron Lichty 25
  26. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 39. Spotify calls its Scrum Teams “Squads” • Each squad has a long-term mission, “owns” part of the UX © Ron Lichty
  40. 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. 41. Managers lead “Chapters” that span Scrum Teams • “Chapters” are manager-led tech organizations • Managers are called “Chapter Leads”
  42. 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. 43. What Gates Teams: Communication © Ron Lichty 43
  44. 44. Communication Gates Development © Ron Lichty 44
  45. 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. 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. 47. Spotify groups sets of squads into Tribes
  48. 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. 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. 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. 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. 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. 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. 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. 55. © Ron Lichty 55

×