Resolutions and Retrospectives

It’s that time again – the New Year, when we look back at the past year and think about what we’d like to change in the coming year, much like retrospectives.

This act of looking back happens much more
frequently on Agile projects, since the Team conducts a retrospective at the end of every iteration. The goal is the same though – to look back at what went well, what didn’t go so well, and what we’d like to change in the upcoming iteration.

Just as it is challenging to make meaningful New Year’s resolutions that you can actually stick with for any length of time, it can be a challenge to come out of the retrospective with well-defined, actionable items that can affect a real change in the upcoming iteration. For example, a Team that is having trouble meshing as a group might focus on the problem in a retrospective, but not come up with a concrete way to address it. “We will communicate better” or “ we will have more trust in each other” are good goals, but not concrete enough to actually change behavior, especially in the space of a short iteration.

An example of a more concrete goal might be that the team agrees to have lunch with each other 3 times a week. Breaking bread together is a powerful act, and would also give the Team members a chance to get to know each other outside of their working relationship.

I talked with a team recently that was not good at estimating, so they decided to give it up! Having planning sessions every iteration provides a great opportunity to get better at planning and estimating. Suppose one of the problems identified in a retrospective was that the Team under-estimated the amount of time needed to develop a user story. If they are tracking their tasks daily, and keeping their task estimates updated, they can analyze that data in the retrospective and see what aspects of the story took longer than expected.

Upcoming Agile & Scrum Courses

The outcome of the analysis could be one of many things – the story wasn’t “ready” to work on, testing or some other activity took longer than expected, etc. Rather than giving up on estimating, the Team could use the results of the analysis in the retrospective to come up with concrete changes to try in the next iteration – for example, having more information about the story before planning, or adding more time to the testing tasks for each story. At the end of the new iteration, they could see if the changes made their estimates more accurate. Even if the changes didn’t help much, they would have learned something!

Retrospectives help teams learn together, but only if the Team develops concrete ways to apply that learning to the way they work together. New Year’s resolutions are similar – if they are too vague (“I’ll work out more”), they are difficult to stick to! So Happy New Year, and here’s to applying what we’ve learned in the past to make this year a great one! And if you are looking for ways to run more effective retrospectives, I highly recommend Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larson.