Manage Learn to apply best practices and optimize your operations.

Self-organizing teams bolster large-scale Agile development

Learn how self-organizing teams can accomplish Agile development on a large scale without chaos and excessive documentation.

Urban legend has it that Agile software development can only work on a small team. Why? It's the communications, dummy! Agile is a people-centric development methodology, contrasted to more traditional document-centric methodologies of the past. So, how do we get dozens of teams all working off of a common backlog without resorting to the old-fashioned, component-based, documentation-heavy assembly line development cycles of the past? In this tip, I share my experiences and advice on self-organizing in large-scale Agile projects.

How do you build a product that is so large that it requires lots of teams to come together? The old waterfall type development methodology said:

  • Before you start doing anything, completely understand the problem and write comprehensive requirements detailing everything that needs to be done.
  • Design a complete architecture to solve all the problems and create specifications for all of the underlying software components that need to be created.
  • Parcel out the work to component teams based on the architecture and specifications.
  • Integrate all of the work at the end and start testing. What could possibly go wrong?

That sort of development methodology describes one of those software factory models of development. Everyone takes their place on the line and does their part! It sort of reminds me of that classic I Love Lucy episode called "Job Switching," in which Lucy gets a job at a candy factory wrapping chocolates on an assembly line (Season 2, Episode 1). She can't keep up, and eventually ends up eating tons of chocolates, stuffing them in her blouse, hat and whatnot. The only problem is that when we develop software this way, it doesn't turn out very funny for anyone involved. Quality suffers. People get burned out. Things that were supposed to work when we integrate them don't function as intended. It's the exact opposite of funny.

The risk of late integration and thrashing

Recognize that thrashing will occur in building software. Building software is a "wicked problem." Such problems are caused by incomplete, contradictory and changing requirements and often occur due to the complex interdependencies. 

Traditional component development leads to thrashing at the end, when it's hard to fix things due to the codebase having gotten so much larger during development. Agile wants the thrashing to occur up front, when the codebase is still small and easy to fix or refactor.

Having a huge team doesn't help, because communications is an n2 problem. Can you imagine a team of 100 people doing a Scrum in 15 minutes or self-organizing around some tasks for the day? How do you spell chaos?

Think feature partitions, not components

Now that we know two ways that don't work for scaling, what's a development solution that does?

We still need a divide-and-conquer solution. That will break down the n for a team to a small enough number to be more manageable and allow proper communication and collaboration to occur. We want our team to work in a fashion that more closely follows the Agile mindset and good Scrum practices.

So, here's an Agile at Scale solution that I use. It looks like this, with time going horizontally, and then looping back onto itself:

Agile at Scale solution diagram

We need:

  • A common product backlog.
  • A single product owner, or at least a committee of closely collaborating product owners.

We start our sprint cycle with a joint presprint backlog grooming. That requires:

  • We get the product owner, Scrum masters and selected team leads together for the session. We want to let the rest of the team concentrate and do the work that's already started in the current sprint!
  • We then groom the backlog, splitting stories where necessary, getting high level estimates from team leads, ordering by product owner, and the like.
  • We then theme, tag, clump or whatever you do to partition the top of the backlog to the teams in a way that fills the capacity of each team to take on related work-- to the best of the knowledge we have now about what the stories are and their estimated sizes.
  • This backlog grooming will take a little longer than the standard version. You have more functionality to work through, and you are going to spend some time thinking about how the functionality gets partitioned.

We then do sprint planning for each Scrum team:

  • Start with the partitioning done in backlog grooming.
  • Break down the stories more. Ask more questions of the product owner. Collaboratively analyze, design and estimate as you go.
  • If you find that there is insufficient capacity to make the sprint commitment (or excess capacity), negotiate stories with the product owner.
  • Come to a team commitment for the work for the sprint.

Now, we hold standard Scrums for the sprint on every team. While we're on this topic, remember:

  • Don't fall into the fallacy of using a "Scrum of Scrums" as a place for Scrum masters to status report their team's progress to other Scrum masters. We should be using standard "big visible information reflectors" (such as Scrum boards) to get standard status out, not holding meetings.
  • Use the "Scrum of Scrums" as an ad hoc venue for working out technical issues between teams, with the Scrum masters getting the people together from the teams that will actually solve the inter-team impediments.
  • Integrate between teams as often as possible, and definitely at the end of the sprint.
  • Depending on your continuous integration tooling and skills, you may end up spending a little more time at the end of the sprint on getting ready for the sprint review, if you haven't been integrating and testing early and often enough. There may also be slightly more divergence in your code repository, because each team's branch may have gone in different directions in the last two weeks. Again, this is an issue if you haven't gotten really good with proper Agile engineering practices.

Joint sprint review and demo:

  • Every stakeholder possible should be invited to this event. 
  • Team members will show off their new pieces of functionality.
  • Scrum masters will share metrics gathered to help people start to think about how well the sprint went and why.
  • This review and demo will take a little longer than the standard version -- you have a lot more functionality to show off (at least that's the plan!)

Standard Scrum team retrospective for each team:

  • We need time to reflect on how things went and look for the root causes of issues that occurred to gain the profound knowledge we need as a team to continuously improve the way we produce software.
  • It's all about "How can we work better as a team?"

Joint teams retrospective:

  • This uses the same cast of characters as the joint presprint backlog grooming.
  • Here, we are looking at the inter-team issues, and looking for that profound knowledge that allows us to do the continuous improvement needed to produce software at an organizational level.
  • It's all about "How can we work better as an organization?"


Agile at Scale can be achieved using Scrum, and without resorting to that old software factory, with its assembly line feeling. But putting together an assembly line for your software is dangerous. As you know, planning components for integration far off in the future raises risks related to late integration and makes it difficult to react quickly to changes in requirements.

The solution outlined here is something you might consider when thinking about how to solve this problem in your organization, with its own customs and culture. This model works for me. And I don't have to eat a lot of chocolate to make it work!

This was last published in August 2012

Dig Deeper on Agile Software Development (Agile, Scrum, Extreme)

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.