An Agile Retrospective is a meeting held at the end of an iteration or at a scheduled interval. In a retrospective, team members get a chance to voice their opinions on things that worked well and items that need improvement. Participants write their concerns and praises on post-it notes that are stuck to opposite ends of a wall. We read and review each topic one by one, take notes, and create action items on things that deserve more attention. Action items are assigned as stories and chores, and sent out to all participants.
We haven't been doing retrospectives since day one. At first they seemed unnecessary as we were a very small team. Whether that's ideal or not is water under the bridge. The fact is, they work. I want to write about the positive effects of Agile Retrospectives and how we've used the feedback and process to continuously improve.
I like to think we follow Agile practices in a non-cultish way. We've been doing this long enough to do away with some of the principles we deemed unnecessary. We only adopt the practices that fit our team and needs. This may not work for everyone, and I would certainly recommend you follow all Agile principles when first adopting the methodology. This will help you learn what works best for you.
We began with a team wide retrospective that included the entire engineering team, QA team, and a few of the product managers. The first few meetings were painful, not so much due to the process but mostly because we'd neglected things that needed attention. I guess I shouldn't have been surprised when the "Needs Improvement" side took over 80% of the whiteboard. Thankfully, we've seen a drastic shift for the better over the years. The "Needs Improvement" side has shrunk and given way to the "Good" side. As we focus on improving based on the constructive feedback, negative items are soon replaced by positive feedback and praise.
The graph above shows the trend based on our retrospective data starting on 2013
We now have team wide retrospectives every two months rather than every six. Sub teams within the engineering department also have smaller retrospectives slightly more often. They use these to discuss items pertaining more closely to their specific work and focus. This has worked really well.
If you're considering hosting retrospectives with your team, I'd advise the following:
- Make sure all team members understand the purpose of the retrospective
- Review previous retrospectives action items quickly before you begin, if you have any
- Keep participants focused and any one individual from hogging the mic or going on lengthy tangents
- Keep the meeting to one hour max
- Have a moderator and a separate note-taker. We rotate these responsibilities at Doximity amongst team members
- Include remote participants and make sure they have local representation for posting post-its on the whiteboard
- Walk away with clear action items and assign them as stories and chores
- Send out retrospective notes to all participants as soon as possible
The list above isn't comprehensive, but it's a good place to start. It has led us to a place where everyone is happy with the process, and the outcome has been nothing but positive. If you try this out with your team, let us know how it goes.
Hope you enjoyed a peek into our retrospective process. I expect to write a few more posts about our engineering culture and processes in the near future. Follow us @dox_engineering if you'd like to be notified about updates to this blog.
Thanks to Jason Seifer and Jey Balachandran for reading drafts of this.
