Agile Zone is brought to you in partnership with:

Esther Derby helps create great work places where people can do their best work and make products their customers value. Not so very long ago, she made her living writing code. She's co-author of Behind Closed Doors Secrets of Great Management and Agile Retrospectives: Making Good Teams Great. You can read more of her thoughts on management, organization, teams, and agile methods at www.estherderby.com Esther is a DZone MVB and is not an employee of DZone and has posted 73 posts at DZone. You can read more from them at their website. View Full User Profile

Solving Symptoms

08.22.2011
| 1244 views |
  • submit to reddit

Recently, I attended two retrospectives.  Different teams, different states, different facilitators. I’m usually on the other side, leading retrospectives.

Both retrospectives followed the “make lists” pattern.  One made two lists  “What worked well” and “What didn’t work well.”  The other made three lists “What worked well,” “What didn’t work well,” & “Issues or questions.”

Once the lists were complete, participants voted on which issues to address and broke into small groups. These groups were called “problem-solving” groups. They were really “symptom-solving” groups.

There may be some agile coaches out there who guide the team to find patterns and underlying causes from these lists. Too often, that doesn’t happen, and the discussion never goes beyond solving symptoms. Too many people teaching Scrum or Agile short-change retrospectives–teaching new ScrumMasters and coaches to make lists, rather than help the team think, learn, and decide together.

Two lists,  three lists–even four lists–are not sufficient. Lists focus on syptoms, as seen from individual points of view. These lists do not build shared understanding. They do not reveal underlying causes, patterns, or structures that influence behavior.

When teams “solve” sypmptons, the problems come back, or the team piles on layers of rules and processes designed to change behavior (I visited one team that had over 20 working agreements–almost all aimed at the symptom level).

It is not surprising to me that teams who do this sort of retro usually find them less than useful.

I’m not saying you have to do retrospectives the way I do them. But please, design and lead your retrospectives to dig beneath the surface, analyze, search beyond symptoms. Otherwise, you are wasting your time.

References
Published at DZone with permission of Esther Derby , author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Timo Lihtinen replied on Wed, 2012/03/14 - 1:40pm

I think rather than solving symptoms… teams should use their resources and find new alternatives. Whether that be a new technique, new software or a new take on the task.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.