From Sprints to Slices: The Art of Agile Team Portion Control (Agile Team Size)

The best team size is one that’s small enough to stay nimble, yet big enough to have someone to blame when things go wrong!


Scrum recommends a team size of seven people plus or minus two. While seven to nine people seems reasonable, in my experience, it’s hard to imagine a Scrum team size of five taking on complex commercial software - that would be something like the Scrum Master, Product Owner, Two Developers and a Tester. If we look to the popular scaling frameworks for guidance on team size, Large Scale Scrum (LeSS) defers to Scrum for team size guidance as according to its principles, “Large-Scale Scrum is Scrum” while the Scaled Agile Framework (SAFe) recommends 10 or fewer people.

Interestingly, in a somewhat dated survey from Scott Ambler, he found that “roughly half (48%) of agile teams are more than 10 people in size and one-quarter are more than 20 people in size.” It’s unlikely things have changed materially since 2016. This is likely due to the state of agile adoption, awareness, and education where some of these organizations are still learning and transitioning to agile and have yet to effectively structure their organizations. While others are possibly managing more complex products and services. Regardless, if your team size is approaching twenty people, that’s far too big. I can’t imagine how painful daily stand-ups would be in such an organization.

Amazon espouses “Two-Pizza teams.” A two-pizza team is one that would take more than two pizzas to feed them. Typically, a large pizza is cut into about 8 to 10 slices and individual eats around 2 to 4 slices of pizza at lunch (thank you ChatGPT, this concurs with my experience). So doing the math here, a two-pizza team is about four to ten people. The two-pizza team definition is less about a specific number, but “more about fostering and pushing ownership and independence down to the team level – from ideation to execution, from ongoing operational improvement to constant product iteration and innovation.” I did see a fair amount of ScrumBut at Amazon which included large team sizes.

In the grand buffet of software development, where Agile philosophies are the chef's special, it seems we're still debating the perfect portion size for teams. Despite the wisdom of Agile sages recommending a main course of 7 ± 2, the industry appetite varies. Some, like the culinary minimalists at Amazon, insist that a couple of pizzas should suffice to sate the hunger of an efficient team—four to ten bellies, max. But let's face it, the world is not made of pepperoni and cheese, and ScrumBut sometimes adds a slice or five, creating a team large enough to need a reservation at the conference table. So, whether you're dining a la Scrum or feasting on the buffet of SAFe, remember that too many chefs might spoil the code, and the perfect team size is like a good pizza: diverse in its toppings, but not so large that you're still chewing when the next sprint comes around.

References:


Comments

Post a Comment

Popular posts from this blog

Be agile about agile!

The democrats and republicans are doing a fine job of "fire-bombing" the centrists in both their parties (I grabbed that quote from an article "It's not easy being George" in this month’s Vanity Fair). And, as I scan the agile groups and blogosphere, it seems the methodologists are doing it as well. Some of us take the "extreme" in extreme programming too literally, and others are holding on to some of agile developments long disproved stigma for far too long. My approach always has been (and hopefully always will be, unless of course I turn out like my father, which all of us eventually do...) a pragmatic one. There are many things I love about Scrum and agile - driving elaboration and development off the backlog, test-driven development, burndown charts, and much more. And there are a some that I could do without (self-organizing teams, developers and testers are interchangeable, ... I blog on these later). An agile approach needs to be tailored to y...
Read more

When Do You Need Agile Product Portfolio Management?

Image
First, let’s define Agile Product Portfolio Management. Agile Product Portfolio Management is a dynamic approach to managing a company's suite of products. It involves continuously evaluating and prioritizing products based on shifting market demands, customer feedback, and business goals. It integrates principles of Agile methodology - such as flexibility, rapid iteration, and cross-functional collaboration - into portfolio management. The focus is on adapting quickly to changes, making swift decisions based on current data, and ensuring that resources are allocated efficiently to maximize product success and overall business value. It's about maintaining a balance between long-term strategic vision and short-term market realities, ensuring the product portfolio remains relevant and competitive.  Agile Portfolio Management is needed when your business and product line achieve a size, complexity, and maturity where decisions can no longer be locally optimized for individual pro...
Read more