Scaling Your Product Team While Staying Agile

Dan Podsedly, SpringOne Platform, 2016Dan Podsedly, SpringOne Platform, 2016
Scaling Your Product Team
While Staying Agile
SpringOne Platform, 2016

Terms Matter: Project vs. Product
2

Project
(noun) proj·ect ˈprä-ˌjekt, -jikt also ˈprō-
A planned piece of work that has a specific purpose (such as to find information or to
make something new) and that usually requires a lot of time.
Projects are finite. They end, and you move on to the next one.
3

Product
(noun) prod·uct ˈprä-(ˌ)dəkt
A good, idea, method, information, object, or service created as a result of a process
and that serves a need or satisfies a want.
Products endure beyond projects that created them; they evolve indefinitely.
4

A product-centric mindset focuses on the
customer and embraces sustainability
5https://en.wikipedia.org/wiki/Windmill#/media/File:Molinos_de_Consuegra.jpg

Let’s talk products!
6

(Yes, this is a real thing, yours for only $1,371.93.)
7

● Successful products spawn competition
● Non-linear increase of complexity
● New and evolving platforms
● Customers expect products to grow with them
8

Growing product = more people, more complexity
How do we organize for sustainable growth?

Origins: Pivotal Labs
● Born in the early Web 2.0 startup days
● Spawned agile team culture at Google, Twitter, eBay
● From 5 to 500 around the world

Pivotal Tracker
● 10 years as widely used SaaS product
● From occasional pair to ~40 dedicated people
● The “transparent core” of every product team

Cult of Sustainability
● Extreme Programming practices
● Sustainable pace; 8-hour work days
● Smooth transition at project end
● The real secret sauce: small, cross-
functional teams
12

“Software development is an intense exercise in collaboration.”
—Martin Fowler
13

Collaborative and Cross Functional
● Product, design, testers, and developers working together
● Shared, highly visible priorities
● Collective ownership, no project manager
14

Roles: The Product Manager
15
● Communicator, emphasizer, and motivator-in-chief
● Big picture vision, hands on fine-grained stories
● Learns, defines, and prioritizes
● Drives consensus but decides

The UX Product Designer
● ”Full-spectrum" design
● Questions assumptions, obsessed with feedback
● Design vision vs. incremental steps
● Found pairing with PM, developers
16

The Product Developer
● Pragmatic, full-stack, polyglot
● Can specialize but not hoard
● Pairs, plays well with others
● Motivated by the collective success
● Red, green, refactor, repeat
17

Team Size: Optimizing for Communication
18

Ten Group
“The basic unit is [a small group of people]. . .this group is bound together by a common
objective, and that the bond of trust and loyalty thus formed can become an extremely
powerful uniting force; that the group needs to decide on (or at least take part in deciding
on) its own objective, and to work out for itself how that objective shall be achieved. . .”
—Anthony Jay, British author, on the centuries of evidence to support the idea
that small groups are the most efficient
19

● Software is more complex than farming (or is it?)
● Optimizing for communication
● How many pairs can one PM and backlog support?
● The “two-pizza rule”
Sizing the Product Team
20
https://commons.wikimedia.org/wiki/File:Pizza-2.jpg

How Many Pair-Brain Perspectives?
21

22

23

Moving to Multiple Teams
24

Paradigm-shifting game just broke the record for iTunes
downloads in the US.
People in the rest of the world and the Android crowd
are feeling left out, the servers go down every lunch
hour, a new platform and API is needed to support all
these apps, and the new CEO is roaming the halls
yelling, “Grow! Monetize!”
How to catch them all?
Case Study: Giantic Games, Inc.
25

Tracker Support Says. . .
From: Pivotal Tracker Support
To: Giantic Games
Subject: Re: We’re struggling!
>> We’ve grown, and our project has gotten very hard to manage. We can’t tell who’s
working on what or when things will get done. Help!
Organize into multiple small teams, embrace a collective ownership mentality!
26

Multiple Teams, Organized Around Platforms
27
iOS Team
Evolve the app, deal with iOS
changes, in-app purchases
Web Front-End Team
Sponsored in-app content,
leaderboards, game tutorials
Android Team
Launch Version 1.0,
in-app purchases
Platform Team
Serve all the apps, scale up,
reduce the outages

A Few Months Later. . .
From: Giantic Games
To: Pivotal Tracker Support
Subject: Got dependencies?
Hi again! We’ve split into small teams. But now it’s hard because every feature spans
multiple teams, all we do is have meetings, and things don’t work together!
28

Symptoms of Poorly Aligned Teams
Products components not cohesive
People feel disconnected from the bigger picture
Back-end team not feeling recognized
Features span multiple PMs and require lots of coordination
29

Tracker Support Says. . .
30

Go Vertical!
31

Conway’s Law
“Organizations which design systems are constrained to produce designs which are copies of
the communication structures of these organizations. . .Any piece of software reflects the
organizational structure that produced it.”
How to apply Conway’s Law for the best product outcome?
32

Organizing Around Product Goals
● Teams focused on product outcomes
● PM + team drives entire feature end-to-end
● Minimized cross-team dependencies
● Product more cohesive to customers
33

Giantic Teams, Reorganized FTW
34
Core Game Play Team
Increase engagement, reduce churn
Scaling Team
Enough with the outages!
i18n Team
Launch in every continent
Monetization Team
In-app purchases—show us the money!

Dan Podsedly, SpringOne Platform, 2016Dan Podsedly, SpringOne Platform, 2016 35

A Real Example: Pivotal Tracker
36

Tracker: Monolithic App, Rigid Horizontal Teams
● Back end, complex single-page web app + mobile apps
● Painful cross-team communication
● Rigid silos
37
Platform Team (6 developers)
All Rails and API work, DevOps
Front-End Team (6 developers)
Web single-page app
Mobile Team (4)
iOS, Android

Toward Product-Oriented “Pods”
38
Story MGMT Pod
Increase engagement (web
and mobile), story-to-code
workflow
USS Enterprise Pod
New enterprise offering,
increase retention at
large companies
Infrastructure Pod
Scaling, stability, DevOps,
special projects (any part
of product)
Onboarding &
Growth Pod
Increase sign-up conversions,
engaged user activations

Optimizing for Pod Rotations
● PMs stay with pods; pods change focus over time
● Developers rotate weekly based on pod needs
● Pairing = low ramp-up cost and knowledge sharing
● Need tools and process consistency!
39

Code and Vertical Slicing
40
● Mono repo for holistic view
○ Mono repo != monolithic architecture
○ More cohesive commits / PRs
○ Components deployed independently
● On-demand environments on PaaS
● Unified CI/CD and deploy pipeline
● Code quality a collective concern
https://www.flickr.com/photos/29233640@N07/9585503388

No Longer a One PM Show
● One uber PM, multiple pod-level PMs
● One visible, shared roadmap
● New product communication structure
○ daily product standups
○ weekly roadmap sync
○ product and design retrospectives
41

Collaborative Design
● New role: Design Lead to own design vision and consistency
● The product roadmap as the collective design backlog
● Weekly design critiques and feedback sessions
● Designer rotation. . .it’s complicated!
42

Bugs, Testing, and Support (featuring Mr. Pierre)
● Who fixes bugs?
● New role: Exploratory Tester
○ Charter-based testing
○ Rotates but worries about product as a whole
○ Proxy for the customer
● Who helps with support?
43

Staying Connected
● All-hands meetings, whole-team retros
● Animated cat GIFs on Slack
● Wine and cheese, happy hour, summer picnic
44

The Next Level: From 5 to 50 Teams*
45
*work in progress

Paving the Way: Pivotal Cloud Foundry
● From OSS project at VMware to 300+
people at Pivotal
● 30+ teams, Pivotal Labs practices
● Major new version every three months
46

Pivotal Cloud Foundry (c. 2012)
47

48

49

50

Growth Challenges
● Many components, dependencies
● Some teams too large (15 pairs!)
● Cross-team communication issues
51

Breaking Down a Large Team
52
TCP Router
HTTP Router
CF API Server
Services API
Identity Server
Container Library
Release Mgmt
Droplet Executor
Health Manager
Runtime Team
TCP Router
HTTP Router
CF API Server
Services API
Container Library
Droplet Executor
Health Manager
Release Mgmt
Identity Server

Conway’s Law, Revisited
● Collection of services is the product
● Scalable architecture with small teams and independent microservices
● Versioned, backward-compatible APIs
53

● Priorities have to align
● Product has to integrate
● Releases have to be stable and coherent
The Biggest Challenge: PM Alignment
54https://en.wikipedia.org/wiki/2012_phenomenon#/media/File:Milkyway_Swan_Panorama.jpg

30 Teams, 30 Product Managers
● One PM, one team, one backlog
● PMs monitor upstream and downstream dependencies
● Product Leads for cross-PM coordination
● PMs have to communicate!
55

Product Org at Scale
56
PM Lead
PM
VP Product
Engineers
Eng Director

Dan Podsedly, SpringOne Platform, 2016Dan Podsedly, SpringOne Platform, 2016 57
Next-Level Skill: Weekly Allocation with 300 Developers

Testing and Integration
● Automation with selective test exploration
● System-level test suites that ensure product works cohesively
● Comprehensive CI pipelines with dependencies and artifacts
● Automated, on-demand acceptance environments on PaaS
58

The Visible Forest
59

Recap: Sustainable Growth in 4 Easy Steps
60

Sustainable Growth in 4 Easy Steps
1. Build small, cross-functional teams
2. Organize these teams around product lines
3. Equip with process and tools that support shared ownership
4. Refactor and evolve!
61

Thank you!
@danpodsedly
dpodsedly@pivotal.io
62

Scaling Your Product Team While Staying Agile

In this document

More Related Content

Viewers also liked

Similar to Scaling Your Product Team While Staying Agile

More from VMware Tanzu

Recently uploaded

Scaling Your Product Team While Staying Agile