Data-driven personal retrospectives for developers

The point of a retrospective is to look for opportunities for improvement. Memories are not as reliable as we think they are, there are numerous known memory biases.

To overcome this problem, systematic tracking gives you raw data you can objectively look at later on to make better decisions.

Personal retrospectives

You should keep track of performance to see how effective you have been in attaining your goals.

“It is impossible for a man to learn what he thinks he already knows.” — Epictetus

Without the proper feedback, it is impossible to recognize when to adjust to the required behavior. It is impossible to discover what effective behaviors to reinforce.

What code areas you spent most of your time? From all you want to learn next, what has the potential to increase productivity? What kind of bugs do you introduce? What would be the consequence of spending more time in test or design phases?

CoderMirror report on defects

Retrospectives are the occasion to ensure you ask yourself questions like these. It is likely you have a rough idea of what are the answers to those questions over the past week or two.

From experience, I’ve found that we often forget details. Perceptions don’t match reality. We have a wrong perception of what happened over long periods.

Cognitive biases: The need for objective data

The main culprit to some of the problems is your memory. Going by memory you’re a lousy judge, your brain rounds things off and likes to make assumptions.

A known memory cognitive bias is rosy retrospection. Rosy retrospection is the tendency to remember and recollect events more favorably than when they occurred. In a personal development context suggests that individuals may be unlikely to revise their actions appropriately. They remember them more favorably than they were.

Another bias is the peak-end rule. We judge based on how we felt at the peak and the end of the period under review and fail to use other information.

Hindsight bias also creates problems when analyzing and interpreting past events. It makes you see the event as having been predictable, judging everything from today’s perspective. Things appear easier than they were, you might undervalue your past achievements.

Effective data collection

Collecting as much data as possible as it happens to generate metrics and logs is the best remedy against our cognitive bias. The depth and breadth of objective data at our disposal on retrospectives make for a comprehensive and productive reflection.

Metrics serve as a diagnostic tool that helps you understand how you spent your time on a project and how to organize your priorities.

When you have collected data over a long time, you’ll know how each change affected the project or your behavior, which metrics have changed, how it affected the bottom line.

Furthermore, when metrics show the need for a change or an undesired behavior to eradicate, they activate cognitive knowledge and strategies that help come up with improvements.

For a long time, I was tracking most of the data manually in spreadsheets. They are flexible and work great when testing what data make the most useful metrics, but manual tracking was time-consuming and error-prone.

Existing time trackers like RescueTime helped collect some information. But as general tools, they focus on reports about time wasted or procrastination. They miss a lot of data collection of great value to developers.

The need to gather metrics to answer continuous improvement questions is why I created Codermirror. It avoids the necessity of manual data collection and gathers all kind of metrics that lead to unexpected insights into we a developer performs his job.

CoderMirror report on task types

Conclusion

Do more of what already works, do fewer things wrong and avoid tiny losses based on what has already happened.

On each retrospective there is potential to make small choices that might not be notable but add up over the long term.

To get the most of your retrospectives, collect data that shows an accurate picture of what happened during development.

Visit Personal Retrospectives for Developers for more information on how to conduct personal retrospectives.