Friday, October 7, 2011

Tribes: A Retrospective Technique

I tried a new retrospective technique this week that seemed to go fairly well. I called it Tribes after the ice-breaker activity that was facilitated by Tobias Mayer this year at Agile Coach Camp US. (Not sure if I should change the name is using and evolving it as a retro technique, but I'm toying with the idea of "islanders" or "migratory swallows".)

Original Tribes:
To facilitate, you get a bunch of folks standing in an open area with enough space for walking around comfortably. Individuals then say, loudly enough for the entire group to hear, some aspect about themselves or something in which they are interested. Other participants then join the person who has said something with which they identify or have in common, thus creating a "tribe". This process repeats as more individuals think of things to say aloud and tribes continually form and reform around new individuals.

As an ice-breaker activity I really liked tribes. It was a fun and active way to see the faces of people who shared things in common with you as well as hear what kinds of things others found interesting while learning more about the whole group in general.

Adapted for retrospection:
In order to adapt this for a retrospective I decided to tweak a few things (though for some forms of retrospective the original format would still be very useful).

To adjust, I asked the participants to only say aloud topics with regard to how the past iteration went or how they would like the next iteration to go. I intentionally wanted to leave this open-ended so any idea was acceptable (went well, could be better, something new to try, confused, frustrated, etc…) Further, I also asked individuals to only change tribes if they felt more interested or aligned with a newly stated topic. While I knew this could greatly reduce the amount of changes, I was hoping it would also take the place of an activity like dot-voting. Finally, I time-boxed tribe creation to 5 minutes.

Realizing that the bulk of the tribe creation activity is only useful as a data gathering technique, I then asked each tribe to elect a "chieftain" who would act as scribe and be willing to share outcomes. Next, I had each tribe spend the next 10-15 minutes attempting to root-cause their topic. During this time I wandered between the tribes, mostly listening and keeping folks from jumping to a solution too fast by asking open ended or socratic questions to help.

Next, I had each tribe spend another 10-15 minutes brainstorming and refining possible countermeasures to the root cause of their topic, keeping track of all the countermeasures they thought viable (at least 2-3).

Finally, the entire team got back together and each tribe shared all key factors, interesting take aways, root cause problems and all viable countermeasures. The entire team then weighed in on implementation of countermeasures creating at least one action item for which one team member took primary responsibility.

All in all, the entire activity took just over an hour.

What went well:
The feedback I received from the team was generally positive. They felt it was very different from other data gathering activities they had done in the past and liked the variance. They felt more engaged during the tribes activity and also felt the small group discussions were more interesting and focused. Also the communal sharing was appreciated and they felt that was the way to go instead of the small groups also deciding on action items.

What could have been better:
The number of participants was only 10, which the team felt worked okay, but might be better if there were more people. They didn't think the activity would have worked very well with a smaller team.

There were only a few ideas (5 total) that were shouted out, and only a few reformations (2) of tribes. Even though we had set a time-box of 5 minutes, all tribe creation was finished in about 2 minutes.

Other ideas or considerations:
It was a nice day so we did this outside, and while a bit warm, the team liked getting outside and being a bit active after lunch. They also felt the company cafeteria would be a good space in the winter.

Perhaps spending a few minutes before tribe creation for each team member to gather their thoughts and jot down a few ideas onto an index card would help tribe creation be more dynamic and fluid.

Using a larger time scale, for example a whole release or an entire month, may be better suited for this activity as people may have more thoughts and ideas remembering over a longer period of time.

Possibly useful for a larger cross-team retrospective (at any time scale). This could also blend some of tribes usefulness as an ice-breaker activity as sometimes people from different dev teams know one another. It would also help people see what problems are common across teams.


The bottom line:
So even though the team thought of some things that could be better, they liked the activity and would like to do it again. They further liked using the activity across a larger time scale. Both the team and I had ideas for further evolutions of this activity, and we would all recommend you try it sometime with your teams!