“The Soup” Experiment

Teams often have difficulty determining the source of issues and focusing on who’s responsible for correcting those issues raised in a retrospective.
Teams often focus on items that are not under their control.  In an effort to help our teams stay focused we ask the following questions:

• How can we make our team better?
• What are our team’s strengths and weaknesses?
• What specific action items can we work on to make our team better?

We experimented with the Circles and Soup collaboration technique.  This technique clarifies who’s responsible for the items.  On a board, draw three circles, like a bulls eye:

1. Team Control – represents items that are specifically under your team’s control.
Examples can include:

• Our team needs 85% code coverage in testing.
• Our team needs to do more pair programming
• Our team needs to switch programming pairs.

2.  Team Influences – represents items that the team can influence but not take total ownership of.  These are items that will typically affect other teams that you can influence or make suggestions on but are unable to directly change them.
Examples include:

• Continuous Integration configurations that would affect other teams
• Changing source control software
• A new tool

3.  “The Soup” – represents items that are suggestions.  These are typically items that you can suggest but have no real influence over.
Examples Include:

• Setting an acceptable company bug rate
• Influence with another department
• Direction of the product.

Here’s an example of what the layout looks like:


Our experience was that for the first few iterations, most of the pain points we identified were classified as “Team Controlled”.  The team was able to identify and execute action items to improve these team controlled pain points.  We repeated the Circles and Soup exercise for each iteration and after 4 weekly iterations, the pain points went from “team controlled” to all the pain points being outside of the team’s control, the only cards that were in team controlled were good points!
I’d says that the team was focused on problems they couldn’t fix, and that frustrated them.  Once they began to realize which problems were with the organization instead of the dev shop, and the dev shop instead of their team, they understood which problems they could solve, which they could affect, and which they could (sometimes) influence.
This is a great way to help your team focus on problems they can actually solve.