Debate #15 – Can an Agile team work on more than one product at a time?

In the 15th installment of my blog series “20 Controversial Topics of Debate in Agile, the topic of exploration is whether an Agile Scrum Team can work on more than one project or product at a time. My opinion on this one is strong (my short answer is “No”), but there may be certain situations where it could make sense.

Having a Scrum Team work on more than one product can work if…

The Product Owner controls prioritization for all Products the team will work on

If you must work on more than one project or product, the Product Owner should own prioritization of the work from all sources. This can get very tricky if there are competing business units vying for the same team. And, just a warning: it can get political.

The organization must trust the Product Owner to be fair in how value is measured and what items are prioritized. The Product Owner will use her best judgment when making decisions about priorities.

image of the word "trust" in sand

Different Product Backlogs feed into one Sprint Backlog

When a team must work on more than one product at a time, each product will have its own Product Backlog. The work from both individual backlogs need to be combined when items are brought into a Sprint to form a single Sprint Backlog.

Multiple Product Owners can choose one person to prioritize

If multiple products need to be supported, and each has a separate Product Owner, one overarching Product Owner must be the final decision maker. That person will need to work closely with the individual Product Owners to make sure that everyone’s needs are being addressed.

There’s a “theme” to organize your Sprints around

One way to address the issue of having a Scrum Team work on more than one product is to find a unifying theme to select items for each Sprint. You could tie this to the Sprint Goal; by having a theme to rally around, it will help the team to focus.

The team rotates which product gets worked on each Sprint

Another option could be rotating which product gets worked on in each Sprint. This way the team can support more than one product, but the team is able to work on only one product, thereby reducing context switching and allowing for focus.

Having an Agile team work on more than one product won’t work because…

It’s inefficient

Remember that “context switching” thing I mentioned earlier, well this is one of the primary reasons I don’t advocate having a single team work on more than one project or product at the same time. Every time you must stop doing something and start doing something else, you lose efficiency. It’s wasted time. And that’s anti-Agile.

Skillsets or expertise may not be available for different projects

If you have multiple, disparate products that need to be supported, one team might not have all the right skills to have a fully cross-functional team. Or, the team members will become jack-of-all trades, but masters of none. This may or not be a good thing.

Divided effort leads to slower delivery

In thinking about the round-robin approach I mentioned earlier, this means that people may have to wait several sprints for their “turn” to come up, which means they won’t get anything of value for a significant amount of time. Again, in my mind this seems very anti-Agile.

Final Thoughts…

The better practice in my opinion is to NOT have a team working on more than one project or product at a time. However, this is reality and with limited resources, it may not be possible to avoid. If you end up in this position, you may be able to work around it; but the more projects being worked on at once, the less efficient and effective the team will be.

So, what do you think? Should a Scrum Team only focus on one product, or can they support more than one?

Next up in this blog series:

  1. Can you use a Sprint 0 in Agile?
  2. Do you need Documentation in Agile?
  3. Is there a “right” way to write User Stories?
  4. What’s the best way to write Acceptance Criteria?
  5. How long should your Agile sprints be?
  6. Should all your Agile teams be run the “same” way?
  7. Which “flavor” of Agile is best?
  8. Can Agile co-exist with Waterfall?
  9. Story Size – What’s an Epic, Theme, Feature…?
  10. Can the Scrum Master be a team member, too?
  11. Can distributed Agile teams work?
  12. How should you estimate in Scrum & Agile?
  13. Is it OK to add items to the current Sprint?
  14. How should you manage your Agile backlog?
  15. Can an Agile team have more than one Product?
  16. What is the optimal size for Agile teams?
  17. Should Agile teams stay together?
  18. How should you handle defects in Agile?
  19. Can a hybrid of Waterfall and Agile succeed?
  20. What are the official roles on an Agile Team?