Third in my Tell Me Like I’m 12 series is Retrospectives.
Retrospectives are a very interesting part of the Agile mindset and process and is really part of what makes it unique. In the same way Agile isn’t married to a fixed plan, it isn’t married to a fixed process either. Its meant to be fluid – ever changing and improving.
Retrospectives are usually part of how that process changes over time. You spend time looking back at how things have been going and make plans for how to get better.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts is behavior accordingly
What does this tangibly mean? It means your team should get together, identify what is broken in your process, brainstorm solutions to change what is broken, and then implement those solutions. And your should do this on some sort of regular cadence – i.e. not whenever you feel like it.
So, what does a retrospective meeting or document look like? How often do you meet? How long do you go for? Lets break that down and discus some ideas for hosting your team’s retrospectives.
Remember the Point
The point of a retrospective is to make your process better. Its not about checking a box or complaining about problems. That means if your retrospective meeting is set up in a way that it is burdensome or creates more animosity, you aren’t sticking to the point.
Chances are your team will bring up problems that make others get defensive. No one likes being told something isn’t going well, especially from their immediate team. There are a few things you can do to mitigate that (tips below), but keep it in mind that if you are the one leading the meeting, you need to facilitate the discussion to move towards improvement. Don’t let team members simply rant and complain or rip into each other for something that went wrong.
Establish a Good Cadence
Retrospectives are a form a feedback. As such, you need to hold retrospectives in some normal cadence to gain the real value from it. Nothing will come from having a retrospective once every year. But having one every week might lean towards wasting time since it can be hard to implement changes to process and behavior within a week.
Try to find sometime between two weeks and every quarter, with the preference for a shorter duration. If you are doing Kanban, maybe its after each release. If your doing Scrum, maybe after every sprint (unless your sprints are really short).
My team is just starting to hold retrospectives. We are currently planning to have a retrospective after each release since we follow Kanban and our releases are usually longer than a month, but not longer than a quarter. We hope it will be frequent enough to gain insights and make it a good habit, but not so frequent that we never get to see if process improvement idea actually worked on not.
The Questions to Answer
When it comes to the actual retrospective, I like to stick to a few core questions.
- What Went Well? – list how your team succeeded or excelled since the last retrospective
- What Went Poorly? – list ways your team lacked or didn’t deliver like they feel like they should have since the last retrospective
- What Did We Lack? – list things that would have helped a process or prevented a problem
- How Do We Improve? – ideas about how improve things in the What Went Poorly section
They are more you ask if you really feel like. Figure out the questions that work for your team. They might get even more specific about How Did Our Deployment Go? or How Are We Feeling About Our Work? Whatever they are, make sure your team finds them valuable.
At the end of the day though, your team will likely have different questions than my team. And this ok! Its good in fact. Like everything in Agile, people and the team performing effectively is more important than a process, so adjust to what your team finds the most valuable.
Holding the Meeting
When it comes time to actually hold the meeting, you want to make sure you use your time well. Many articles exist about how long a retrospective should be and how much time should be devoted to each section. I don’t prescribe those same time limits – but I do think you should be able to wrap everything up in 30 – 45 minutes.
First, I usually start the meeting with either a whiteboard or even a shared document (Google Docs; Dropbox; Evernote; etc) with all of the questions listed posted. To begin, I try to start with evaluating if our ideas for improvement were effective or not and put them in the Went Well or Went Poorly sections. After those are addressed, I then let people throw out ideas for any section without a lot of interrupting.
After a few minutes, there is usually a break as people realize the ones that really stand out in both categories. You can spend some time recognizing those things that went well and congratulate the team on those items – especially if they were things previously identified as going poorly.
After that, you can walk through what went poorly and start asking the why questions. Was it just one person who felt that way? Did everyone have a hard time with a particular process or development issue? Get a sense for the depths of an item in this category. Something as simple as “We didn’t communicate well” is too broad – it needs to be broken down before you can identify solutions to change it.
Next, spend some time brainstorming ways to improve all of the things in that category that you flushed out. If it turns out that the developers are having a hard time getting code reviewed, maybe you start assigning them more specifically. Maybe you move away from code reviews altogether (thought I don’t necessarily recommend that approach). Either way, you need to work as a team to come up with a way to address the problem and then give specific action items you can walk away taking.
Retrospectives Are A Necessary Evil
In many ways, a retrospective is a necessary evil. In a perfect process, a team would never have to make adjustments to anything, since they would be perfectly in sync. But of course, there are not perfect teams (and if there were, I would be sad to join one since I would make it imperfect), so we need to a forum to make teams and processes better.
Additionally, a great team wouldn’t need a meeting either. They would be so good at communicating and making incremental changes that a meeting at the end of every sprint/release or whatever woudldn’t be needed.
How has your team used retrospectives to improve? What tips do you have from hosting them?
Till next time!