Conducting a retrospective at the end of a sprint is a core Agile practice.  It constitutes one of the key ‘meetings’ for Scrum (along with sprint planning, sprint review, and the daily scrum meeting itself) and when done well it provides a valuable lever for the continuous improvement of the development team.  The main scrum team I work with has been holding a retrospective at the end of our sprints for years, but our most recent one felt like one of our best so it prompted me to write down a few thoughts about what made it so meaningful.

For most of the past couple of years I have structured what I’ve called ‘Clint Eastwood retrospectives’ as we examined the good, the bad, and the ugly from our sprints.  This structure started as a simple way to capture what went well, what went poorly, and what outside things impacted our sprint plans; after a couple years however it became too rote and our retrospectives tended to be fairly superficial.  So at the start of the year we switched to a new simple structure: asking what we should keep, what we should stop, and what we should try.  In addition to this small shift in the format of our retrospectives we also started treating them with renewed seriousness, seeking to recapture the possibility that retrospectives could provide valuable feedback on how to improve our development process.

So far the results have been noticeable.  Our first retrospective surfaced some good practices for us to keep (a growing emphasis on pairing and a commitment to setting aside time for refactoring), an important thing to stop doing (haphazard and inadequate planning), and a commitment to try communicating better with other teams when we faced dependencies.  But the key impact came when our second sprint retrospective fed into planning for our third sprint.  I urged the team to use some of the time between these two ‘events’ to decide on two items in the ‘try’ category that we would actually plan to implement in our next sprint.

The team was clearly energized by the plan to adopt better ways to track the progress of items being worked on to make sure code was well reviewed and automated tests were developed before an issue could be considered ‘done.’  We also committed to shifting the way our large team plans for each new sprint to make sure we focused on the most important features and fixes and we had well-defined items in our sprint backlog so the team would know what had to be accomplished.  This quick feedback loop linking retrospectives and planning provided insight and energy that I hope will sustain us going forward; it certainly highlighted some key areas for me to improve in my own performance as product owner and I think gave similar direction to other members of our team.

Two years ago (back in January of 2014) I started a ten-part series on Agile planning with this post.  My plan all along was to finish with a post on retrospectives because I am convinced that reflecting back on what went well or poorly and why is fundamental to continually getting better at both planning and action.  If I had to conduct a retrospective on my own plan to write about Agile planning, I’d have to give myself poor marks for execution and estimation; a lot of unexpected things have intervened in my plans over these two years but I’m not happy it took me this long to complete this series of posts.  Hopefully thinking back on this will help me get better at blogging, but if I’m honest I have to admit that in truth it’s not that simple.