Retrospective: difference between gathering data and generating insights?

Question

I am reading a book called Agile Retrospectives and the author suggests splitting retro's into 4 stages. Two of the stages seem so similar:

Gathering Data and Gathering insights, seem the same as I cannot imagine some of these exercises would work if you did both a gathering data and generating insight exercise.

Some of the generating insight exercises require you too...gather data! Very confusing. Are people using both of these stages in retros?

Does that make sense? Any thoughts?

Update: My confusion stems from my inability to link to a gathering data exercise with a gathering insight phase. That is my problem.

For example: I make the team brainstorm what went well, what did not go well in the data gathering stage, then do I simply set that aside and move onto a data insight exercise which also, in it self, requires the team to write a bunch of ideas down.

Answer 1

The two stages require a different kind of thinking. They build on each other, together with the other stages, to come that actions that will help the team to improve effectively.

• Gather data is about getting information about the problem, both facts and feelings. The team will be working towards creating a shared image of the current situation based on what they know now.
• Generate insight is about coming to solution on how to deal with the problems that gather data has revealed. You are looking for solutions. In that process you may need to dig deeper, hence get extra information/data. You might also see this as iterating between gather data and generate insight.

Main thing to be aware is to get a good enough understanding of what the real problems are before trying to come up with solutions. This increases the chance of coming up with effective actions that will help to solve the problem or prevent it from happening in the future.

Answer 2

I think the idea behind the two separate parts (I've done something similar) is this

• Gathering Data: focussed on 'what happened' and should really be about facts rather than any interpretation. Ie 'The builds we're broken too often' or 'Testing component X was delayed meaning we didn't have time to resolve the bugs before the end of the sprint'
• Insights: focussed on interpretation of the data and what should/could be done in future to avoid the same situation (or encourage the same situation if it was a good thing:) ). Ie 'We need to shorten the time the builds take so people get feedback sooner and can fix their crappy code!' etc.

The idea here is to avoid too much discussion and possibly hurt feelings when working out what happened. By timeboxing that part of the meeting you can then move onto discussion of what should be done. Otherwise too long can be spent on the first thing someone mentions, you end up down a rabbit hole and the meeting missed the opportunity to discuss something actually important.