Matthew Bussa's Blog

September 8, 2010

“The Soup” Experiment

Filed under: Agile — matthewbussa @ 12:19 pm

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:

  1. How can we make our team better?
  2. What are our team’s strengths and weaknesses?
  3. 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:

circles-of-c-i-soup-blank-small

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.

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: