scaling agile teams - synerzip.com · spotify: kniberg calls scrum teams “squads” • each...

Scaling Agile Teams

Ron Lichty | Ron Lichty Consulting

[email protected] | www.ronlichty.com

* Addison Wesley (Amazon, BarnesandNoble, InformIT.com, Safari)

http://ManagingTheUnmanageable.net <-----tools, excerpts, more rules of thumb

© Ron Lichty 2

*

© Ron Lichty 3

http://ManagingTheUnmanageable.net <-----and pointers to video training

The Study of Product Team Performance

http://www.ronlichty.com/study.html

4© Ron Lichty

Ron Lichty,

Managing Software People & Teams

SOFTWEST

Untangling the Knots; Making Things Hum

• process

• culture

• communication

• planning

• rigor

© Ron Lichty 6

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

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

What’s the Ideal Team Size?

• Give me some answers in the chat window

© Ron Lichty 9

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

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

What Gates Teams: Communication

© Ron Lichty 12


Lines of communication multiplicativen(n-1)/2

© Ron Lichty 14

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

Ideal Team Size: 1





• so what’s the issue?• not many applications these days a single programmer can write

© Ron Lichty 16

Ideal Team Size: 1





• 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

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 frameworksMEAN - MongoDB - Express.js - AngularJS - Node.js

• ...and we run out of engineering bandwidth

© Ron Lichty 18

Ideal Team Size: two pizzas

• Jeff Bezos:“5-7 people”

© Ron Lichty 19

Ideal Team Size: two pizzas

• Jeff Bezos:“5-7 people, depending on their appetites”

© Ron Lichty 20

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

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 DevelopmentForming / 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

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

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

Cell Division

• Cleave off a small team

© Ron Lichty 25

Cell Division

• Cleave off a small teamSteve 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

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

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

How to Split the Team

• The easy route: splitting by components

– grouping like-minded, like-tooled,

common-best-practices people together

© Ron Lichty 29

Teams Split by ComponentsWeb

Mgr

Databas

eMgr

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

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



– 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




• The effective route: feature teams


– every team has every skillset needed to so deliver

© Ron Lichty 33

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

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


© Ron Lichty 34

How Distributed Teams Change in Agile

From this…


QA

Analytics

Biz Logic

Web Dev

DB


© Ron Lichty 35

To this…

How Distributed Teams Change in Agile

Feature

Team

Feature

Team

Feature

Team

Feature

Team

Feature

Team



© Ron Lichty 36




• The effective route: feature teams


– 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

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

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


© Ron Lichty 38

Spotify calls its Scrum Teams “Squads”

• Each squad has a long-term mission, “owns” part of the UX

© Ron Lichty

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, …

Managers lead “Chapters” that span Scrum

Teams

• “Chapters” are manager-led tech organizations

• Managers are called “Chapter Leads”

Splitting Teams: a second trap



• 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

Splitting Teams: a second trap






– 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

Splitting Teams: a trap solution






– Spotify groups sets of squads into Tribes

– Zenefits groups sets of pods into Superpods

© Ron Lichty 46

Spotify groups sets of squads into Tribes

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

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

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

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

Ron Lichty Consulting • Software leadership, coaching, training, consulting:

– http://ronlichty.com, [email protected]

• 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 ManagerManaging Software People and TeamsZero to Agile in Three Days

52

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

Ron Lichty Consulting • Mentoring, coaching, training, consulting:

– http://ronlichty.com, [email protected]

• 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 ManagerManaging Software People and TeamsZero to Agile in Three Days

54

Your Trusted Agile Software

Co-development Partner

1. Accelerate delivery of your

product/technology

roadmap

2. Address technology skills

gap in your in-house team

3. Save >50% with India

based software

development talent

4. Leverage US based

professionals to make it

easy for your inhouse team

to collaborate56

Representative Clients - 14+ Years

…100+ more

Upcoming Webinar

Performance Reviews That Don’t SuckWednesday, February 13, 2019

@ 1pm ET | Noon CT | 10am PT

Presenter:

Todd LittleCo-Author Declaration of

Independence for Agile for

Agile Leadership

Texas4100 Spring Valley Road

Suite 308Dallas, TX 75244

Tel: +1.469.374.0500 | Fax: +1.469.322.0490

New York

India3rd Floor, Revolution

Mall,Above Big Bazaar,

Kothrud,Pune, India 411 038

Tel: +91.20.67283222 | Fax: +91.20.67283222

[email protected]

Silicon Valley

scaling agile teams - synerzip.com · spotify: kniberg calls scrum teams “squads” • each...

Documents