Retrospectives are a surprisingly difficult part of Scrum. Retrospectives, or retros, are a way to repeatedly inspect how everything is going, to have important (difficult) discussions and to think about systemic things that are larger than anything that you can handle in the daily scrums or in the middle of the daily grind in general. Retro is always held at the very end of each sprint and the only goal they have is to improve things.

Retros are a part of the cyclical and empirical nature of Scrum. You inspect, adapt and inspect again.

Why do we need retrospectives? Can't you just constantly improve things? Why do you need to wait until the end of the sprint to discuss if things could be better? This is another "yes, but no" situation. In theory you could improve constantly. Actually you should always be doing that. If you have a problem, just fix it. But in addition of that, it's HUGELY important to have dedicated times when you dig even deeper and discuss even larger issues. Anyone who has been coached or has had a mentor knows how important it is to be able to step aside for a moment and concentrate on just thinking about what's going on. It's another opportunity to actually adapt instead of just reacting.

So how do retros work with scrumlife?

Very straightforwardly, would be the easy answer.

There's very little you need to tweak when moving from team-based software development to solitary life hacking. I have one week sprints so at the end of each week/sprint, I have a retro to think about how I did and what I could improve. Retro comes after the sprint review. Even if both of these ceremonies could be described as me thinking about how the week went, there are some clear differences between these two.

In the sprint review, the world tells you if it is happy about the things you built. When reviewing, I'm interes­ted about how I managed to move towards the sprint goal and how were the things that I finished: am I happy with the blog posts, did I manage to have some discussions, did I clear off my sprint backlog?

In the retrospective, you tell yourself how to be better about building previously mentioned things. Here I want to think more generally about the whole process and if there are any impediments I've noticed and might want to try to get rid of: was it hard to stick to the plan, why, what can I do about it?

At the end of the day most of these ceremonies just look like me writing unstructured text under some heading. That already sort of works, but I feel having clear structure on top of that is especially helpful as I'm doing this by myself. Retrospectives are notoriously hard to get right. Therefore I want to have an actual plan and a format for them.

First thing I want to incorporate into retros is thinking about the Scrum values. This gives me one easy way to practice applying the values to real situations. I'll start by always picking two values to think about in each retro. I'll cycle one out and one in every week, so for example first week I'll do Focus and Openness and next week Openness and Commitment, and so on. How did I do concerning focus this week? Did I concentrate on what I was supposed to? How much cat videos did I watch on YouTube and what should I do about it?

For the second part of retro I'll be doing Mad, Sad, Glad. I really like this format as it bring feelings into the mix. Feelings give so much information and make it easier to get started. "Start, stop, continue" for example is so blatantly boring and smells of engineers pretending to be machines, that I feel it's much less efficient. Being mad shows that you care about a thing. You'll remember it better and will want to do more about it too.

This is my first design on how do retrospectives. I'll probably notice very quickly if this kind of retro serves me well or if I need to tweak or change it around. It's obvious that this whole scrumlife project is pretty exploratory. One way to do this would have been just to iron things out for a year and then present all the findings without all this flailing around but that wouldn't have been very agile, right?

This way I have the very real benefit of releasing early and maybe getting some feedback already along the way. So if you have any ideas or opinions, let me know!