As internal coach, I get to facilitate quite a lot of retrospectives. While most go smoothly, every now and then teams seem to get stuck when trying to analyze their data. As I design most of my retrospective based on the phases proposed by Esther Derby and Diana Larsen in their excellent book Agile Retrospectives, I tried to find out what might have gone wrong while Gathering Data.

Intangible Timeline

While reflecting about some retrospectives that felt awkward for the team and me, I noticed certain similarities. The most apparent pattern I came upon was what I like to call Intangible Timeline. Intangible timelines leave the team without any real input for the Generate Insight phase. Either everything seems already analyzed yet no conclusion is possible or everything is so abstract that you would actually need another Gather Data phase to make sense of it.

Let me give you some examples of what kind of data can make a timeline intangible and what you can do about it as facilitator:

Non-events

These are the post-its that usually end up above, below or to either side of the actual timeline because they don’t really fit in. They represent ongoing or repeating “facts”:

• The customer keeps ignoring our emails.
• My computer is too slow.

While these statements might be patterns that will come up when analyzing the timeline, accepting them as actual data might hide more important issues. When someone puts a non-event onto the timeline, I now ask questions like these:

• What makes you think that the customer ignores your emails?
• When did you notice that your computer is too slow?

Ideally, this will lead to tangible data:

• Sent mail with questions about the business rule to Mr. Johnson, but never received an answer.
• Running the full suite of integration tests after merging in Paul’s branch took 4 hours.

Judgemental statements

While the Prime Directive, the team’s working agreements and an observant facilitator will usually be enough to prevent blame and finger-pointing, there are more subtle forms of judgment. Have a look at these examples:

• Too much time wasted at the weekly status meeting.
• Lost a day fighting the complicated JavaScript library.

Too many of those can easily lead to premature or unsuitable actions being discussed. Try to find the real events by asking questions like these:

• Why did the status meeting feel like a waste of time for you?
• What was so difficult that it took you a whole day?

Aim for answers like these:

• With the critical bug not yet fixed, I felt that I should rather be coding than sitting in the status meeting.
• I haven’t found any documentation on how to create the dialog box for feature X and needed almost six hours to figure it out on my own.

Low Resolution

Have you ever ended up with a timeline consisting of ten post-its with two words written on each? That’s a low resolution timeline. Typical example events are:

• Sprint planning meeting
• Release of version 1.4

There is not much you can actually do with this level of granularity. Relevant information and controversial opinions are hidden behind a summary that everybody can agree with. Try to dig deeper with questions like these:

• Why do you remember this particular sprint planning meeting?
• What was the most important observation you made during the release?

There might be hidden treasures:

• During the last sprint planning meeting I felt like you were ignoring my concerns about the ERP system’s interface when deciding to include feature Y into the sprint.
• When releasing version 1.4 we had to start over twice because the automated schema migration failed on a certain table.

Thought-reading

Thought-reading happens whenever someone assumes the perspective of another person while describing an event:

• Mrs.Jones didn’t like the new UI design.
• We were frustrated by the low velocity.

This is a recipe for speculation, misinterpretation and generalization that can easily be avoided by asking about the actual observation:

• What makes you believe that Mrs. Jones didn’t like the new UI design?
• Why do you think the others were frustrated by the low velocity?

Speaking for themselves, people will mention events like these:

• I overheard Mrs. Jones telling Mr. Smith that it takes her twice as long to do her work after the UI redesign.
• Last monday, Fred and Jim mentioned how frustrated they were with feature Z taking so much longer than our estimate. We discussed the situation, but I still felt like we needed to take some action.

Conclusion

I’m sure there are many other examples, but these categories I came upon quite often. I noticed that teams were able to produce a more detailed picture of their project when I kept asking those questions. What might have passed as one big event became a series of diverse observations. I also noticed that there seems to be a natural tendency towards Intangible Timeline as we are trained to analyze and interpret the world around us. As facilitator, I now try to be aware of the patterns I described in this blog and combat them with open questions when necessary.

Have you noticed similar patterns in your retrospectives? How do you react as facilitator? Feel free to leave a comment if you have a story to share.