You've just finished a project! HOORAY! Whether you did it alone, in a pair, or in a group, it's DONE. Thank goodness!
It was a lot of hard work and you're tired. Time to take a break and just turn your brain off for a while. You've earned it, right?
Not quite! You're not done just yet. You still need to run a retro on that big chunk of work you just powered through.
Whether you're building a project (where the point is to learn and grow as a developer) or a product (where the point is to deliver business value), that finished work is always win worth celebrating... but what does "finished" mean?
Software is always changing. Tools get updated, libraries get deprecated, and companies decide to pivot into new languages.
The highest aim of the developer, then, is not to pile up a bunch of chunks of good code, but to constantly strive to become a better coder.
That's why we retro! Because that last bit of code might be written, but more code will need to be written tomorrow, and we want to find even more joy in tomorrow's work.
A retro is just a structured, regularly scheduled way of looking back on a certain timeboxed period of work (usually a week or two, sometimes referred to as a "sprint"), reflecting on the whole process that happened, and setting intentions about how to improve the next period of work.
There are lots of "frameworks" or outlines for how to retro, but most methods involve pointing out both the positive and negative aspects of the work and trying to be specific about next steps.
Many times, a team will start retroing using one method and then "retro their retro" after a few work periods to figure out how their retro process itself can be improved. A meta-retro.
I just finished a solo project and I want my next one to be better than this one was.
Even if I had a great experience and got a lot done, why not shoot for a phenomenal experience and even more finished work next time around?
So I take 20-30 minutes to reflect and write down some answers to the following questions:
1) What things did I do that I'd rather not do next time? (technical mistakes, workflow hiccups, bad time management, excessive self-critique, etc)
2) What things did I fail to do that would make my next project better? (drawing out a visual schema, wireframing the app in more detail, sticking close to my user stories, making myself type things by hand instead of copying so I learn them better)
3) What things did I do great that I always want to do on future projects? (listening to pump-up music to start the day, using pry to test my work in small steps, keeping my git constantly up to date with small commits, pausing to check understanding against docs, a peer, or a teacher, taking regular breaks to recharge and refocus)
By applying a structure like this to multiple projects over time, and saving my notes, I know I'll gradually be able to spot patterns in my work and improve my memory of everything I did during a project process.
We just finished a group project and we're proud of what we accomplished together.
Maybe we learned some great habits from one another and want to share some shout-outs. Or maybe we had to work through some tension as our differing work styles clashed.
We know we may work together again, probably pretty soon. So we really care about sharing clear, specific, non-judgemental feedback about how our process went.
So we go through the three questions above, as a team.
1) What things did we do that we'd rather not do next time?
2) What things did we fail to do that would make our next project better?
3) What things did we do great that we always want to do on future projects?
Often we start with a few quiet minutes and a few stacks of post-it notes. Everyone writes their thoughts down for each of the three categories, and then we chat about the notes as a group Or perhaps we go around the circle and take turns answering each question one by one.
The important thing is that everyone is heard and that we all feel confident that we can communicate as a team on future projects.
Sometimes a team retro will include individual feedback, or a discussion ends up leading in that direction. First of all, feedback is scary sometimes, and it's ok to feel nervous!
It's generally best to give and receive feedback when it's as fresh as possible, especially if the feedback is critical/constructive. What better time than right at the tail end of project work?
SO...
When I give feedback, I keep it specific. "I wasn't feeling your energy" doesn't help someone zero in on my issue. I could instead try something like "yesterday afternoon I was distracted and worried by how you expressed your frustration at that bug in the driver code."
When I give feedback, I keep it action-based. Is my issue something that can be acted on in a concrete? (Specificity goes hand in hand with this!) Instead of "You were a great pair" I would say "I really liked how you took the time to check in each morning even when I was in a big hurry. It helped me slow down and remember I didn't have to panic because I wasn't working alone on this."
And of course, I refrain from giving "feedback" that's actually insults, or "counter-feedback" that's actually lashing out defensively.
Furthermore, I want us to find the joy in our work! So I try to give way more positive feedback than negative, basically looking for every opportunity to reinforce the behaviors that help me do my best work.
On the receiving end:
If someone gives me a compliment, I don't deflect it. I let myself feel proud of the specific behavior mentioned, and I make a note to do that thing more next time.
If someone tells me they felt friction or discomfort because of something I said/did (or failed to say/do), I refrain from challenging with anger, wallowing in despair, or avoiding the topic until it changes.
Instead, I thank the person for being brave enough to give the difficult feedback and try to work out what small action I could take in future projects to prevent that friction or discomfort.
(This may not just apply to teams! If I'm working solo and I find that retroing is difficult because I keep hating on myself or my work, I might pause my thought process and try to write down a few more positive things I did, or imagine I'm reviewing a good friend's project instead of my own - how would I talk to my friend?)