Lessons in Building Well-Formed Scrum and Kanban Teams
In the early days of Amazon, Jeff Bezos set a rule: teams shouldn’t be larger than what two pizzas can feed, no matter how large a company gets. Setting this rule of small teams meant individuals spent less time providing status updates to each other and more time actually getting stuff done. It also allowed team members more time to focus on continuous improvement.
PagerDuty, like Amazon, has a strong culture of continuous improvement. We’ve experimented with and learned a lot about building well-formed teams. In this blog post, I’ll be sharing our recipe for making a well-formed team so that you can benefit from these learnings, too.
What We Did: An Experiment in Team Size > 2 Pizzas Can Feed
We started with two Scrum teams, each with their own team charters and roadmaps. We had just finished a team health check survey for both teams. One of them was quite happy and optimistic about where they were headed and hitting their goals. The other team was unhappy and pessimistic about their roadmap, and had trouble meeting their Sprint Commitments (work commitments within a 2-4 week timebox).
Due to team resourcing and morale issues, the decision was made to merge the two teams. We ended up with a supersized Kanban team tasked with building out features for our largest customers while simultaneously modernizing our monolithic architecture.
(You may be wondering, why did the team choose Kanban versus Scrum? The thought was, for a supersized team, Scrum would have too much overhead. Can you imagine doing Sprint Planning for a 14-person team?)
What Happened
You may be skeptical at this point about whether or not this team was setup for success. And after reading this far, you should be. Here’s the TL;DR on what happened:
The supersized team was tasked with a supersized workload.
Result: Lack of focus, 5-6 workstreams for the team at any given point in time.
Two team roadmaps were smushed together, parallel work streams were deemed equally high priority for the team.
Result: Agile forecasting and planning challenges.
Due to team size and team dynamics, the team had stalemates on process improvements.
Result: Limited process improvement for the team due to a lack of consensus.
What We Learned
The biggest lesson we learned out of this experiment was that team size really does matter. The Jeff Bezos two-pizza rule is backed by organizational research. Organizational psychologist J. Richard Hackman points out that, as a team grows, the number of links between people makes communication increasingly difficult. If you take a basic two-pizza team size of, say, 6, that’s 15 links between everyone. Double that group for a team of 12, and it shoots up to 66 links.
The communication difficulties of a 14-person team were most obvious during team meetings. It was hard to make the meetings effective, and we all had to become better listeners. It also became harder to reach a consensus and more likely to hit team stalemates on process improvement ideas.
The Ringelmann Effect was also at play for our supersized team. This is the tendency for individual members of a group to become increasingly less productive as the size of their group increases. This effect has even been documented in physical activities such as tug-of-war.
And finally, we learned that limiting Work In Progress (WIP), a core principle of Kanban, applies to teams of all sizes. Any team with 5-6 projects worked on in parallel is not set up to succeed, and is more likely set up to miss forecasts and lose focus.
What We Do Now
Today, Delivery Teams at PagerDuty are formed in a way that optimizes their effectiveness. Well-formed teams are able to move fast on the most important initiatives, and have consistent product delivery.
Before forming a new delivery team, we make sure that all of the following boxes are checked:
[ ] Clear Team Ownership Specification: The team has a charter that states what they do and what they own, and the team’s ownership doesn’t overlap with other teams.
[ ] Defined Customers: The team understands who they are building for. A team can have several customers.
[ ] Own Their Roadmap: The team is able to take requests from customers, prioritize these requests, and put out a prediction of when those requests can be fulfilled.
[ ] Self-Sufficient: The team has minimal external dependencies so they can focus and get stuff done.
[ ] Leadership in Place: The team has a Product Owner (to be the voice of the customer, Technical Leadership (to ensure good architecture), and Managerial Leadership (to keep the team aligned on business objectives and keep team members productive and engaged).
[ ] Sized Appropriately: Teams are sized based on guidelines from the Official Scrum Guide: Three to nine team members. Fewer than three team members decreases interaction and results in smaller productivity gains, while more than nine team members requires too much coordination.
Share Your Learnings
Have you had similar experiences while working toward building well-formed Delivery Teams? What are your team-building best practices? We’d love to hear from you in the PagerDuty Community.