Personal Retrospectives for Developers

How a simple habit is helpful to become a better developer.

Both on a team level and on a personal level there’s always an opportunity to improve, to do things better. The more you become aware of your actions, and the more you are open to experimenting, the better your potential for improvement.

The practice is similar to how agile teams perform team retrospectives. These meetings are an essential practice of high performing teams according to research made by Noopur Davis. His study found that irrespective of organization size, methodology and project duration, teams that plan and track improvement actions exceed customer expectations.

“We do not learn from experience. We learn from our reflection on experience” — John Dewey, educational reformer

Reflection enhances the learning process. To learn from experience it is needed to draw conclusions from what you did. Notice patterns, see clearly what happened, how affected your work and use it to improve your working practice.

A study by Harvard Business School found that training and reflection give better results than training alone.

Deliberate practice is the most effective training technique whether you are an athlete or a software developer. Two common methods that drive what to practice on are measurements and coaching. However, insights from retrospectives can improve and complement what aspects need to be worked on.

Retrospectives will never replace a good coach but can serve as a low-cost replacement. Coaching is essential to sustain an improvement process in the long term. Good coaches find ways to improve your practice, track your progress and hold you accountable for your efforts. Personal retrospectives can be seen as finding time to be your own coach.

Steps for an effective retrospective

Getting started can be a challenge, but usually, after three sessions you begin seeing the value and quickly becomes a habit you don’t want to quit.

For first timers, the best advice is to start small. Pick a frequency and length that you can safely maintain and book a time slot in your calendar.

A good start is to keep your sessions at 15–20 minutes and with the same frequency as your team retrospective. Ideally, schedule them the same day or the day before the team retrospective.

Another approach is to book time on weekends, to make sure you find in your agenda a quiet time to reflect.

A typical session has the following steps:

Follow up

Spend the first 5 minutes following up on the action points from your last retrospective. It is important to hold yourself accountable for your actions and make sure they work and are still relevant.

Gather data

Identify what went well and what could be improved. Being effective requires some preparation, you don’t want whatever idea that comes to mind at that moment.

Start gathering data about what happened since your last retrospective. Your goal is to collect objective information to help you double check your experience with reality.

Review your email inbox, bug and issue trackers or commit logs to get a better picture. If you keep a journal, this is the moment to go over your notes.

There are alternatives to manual facts collection. For example, CoderMirror integrates with IDEs to create reports about your work. These tools help to gain insights without effort.

Generate insights

Brainstorm about what to improve based on the information gathered in the previous step. For the next step, you only want to focus on items with a promising impact on your work. When loads of ideas emerge group them by similarity and prioritize according to your goals.

Action points

If there is no change in your behavior after your reflection, the reflection had no value. Impactful action points should be your main priority.

Avoid planning more improvements that you can realistically handle. A safe bet is to consider 1 to 3 actions points.

Small action points are more likely to happen and compound over time. Don’t ignore them.

The session concludes when concrete actions to take are clear. Remember to schedule your next retrospective at this point.

Keep experimenting

When your current questions don’t result in useful actions, turn to fun ideas or some thoughtful questions for a fresh set of questions.

Change from time to time the set of questions to uncover insights you might have missed before.

Any tool that you feel comfortable with for taking notes is enough for a retrospective. Use a notebook or Google Docs, or organize your ideas in a Trello board or spreadsheet.

ConclusionPhoto by Jon Tyson on Unsplash

With personal retrospectives you think critically about your work to generate actions to improve on some aspect.

There is evidence across many disciplines, from educators to nurses to executives, that self-reflection is a useful practice that boosts your career.

A biweekly session of as little as 20 minutes has the potential to make a difference to your skills as a developer.

What are you waiting for?

Personal Retrospectives for Developers was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.