Wednesday 8 February 2017

Thoughts in Retrospective

  No comments
Agile retrospectives are something that all agile teams are by now familiar with, to one extent or another. Retros are built into the manifesto in Principle 12; At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. Retros were built into frameworks such as eXtreme Programming and Scrum, and have now become a staple of the cadence we expect to see in any kind of agile team. Given their high significance in our processes, and being process managers, retrospectives should be of the highest priority to ScrumMasters.

One thing that we hear spoken about often in agile circles is how it avoids the death marches of software development because we check in frequently enough that we should know that something is going wrong early enough to fix it. Retrospectives are the mechanism that we use to highlight problems and stop us from doing the things that are hurting us. I have heard people talk about agile being worse, because the retrospective gets everyone talking about the problems every week, and yet they don't solve anything. If anything, this highlights even more the importance of retrospectives and how, if they're not good, they can do more harm than good.

In order to perform the most effective retrospective, you want to create a fun, safe, and creative environment that gets the team thinking about the past few weeks. As a developer I had more of the death march variety of retro, than the fun and creative kind of retro. The gloom of heading to a room with my team mates to sit and list What Went Well, What Didn't Go Well, and What Could We Do Better, did not fill any of us with joy. I can see how people would consider retrospectives a death march if this is what they experience sprint after sprint. The worst thing is this kind of retrospective requires a high level of self-awareness, and generates a low amount of quality data.

As a ScrumMaster, when I enter a retrospective I'm expecting to come away with at least one thing for the team to improve over the next iteration. If we don't walk away with something to work on, then we're are failing to inspect and adapt, and most definitely failing to be agile. If the team hasn't been able to come up with anything of significance to improve then I as a ScrumMaster have failed to help the team.

In the book, Agile Retrospectives by Esther Derby and Diana Larson, it is recommended to have five stages to a retrospective:
  • Set the Stage
  • Gather Data
  • Generate Insights
  • Decide What to do
  • Close the Retro
Setting the stage serves the facilitator two fold. Firstly, it is an opportunity to understand how the team as a whole is feeling. There are some great exercises out there that get the team to rate the last iteration based on various scales. If someone doesn't talk in the first few minutes of a meeting, then they are likely to feel they have tacit permission to not talk throughout the rest of it. The second benefit is that you can avoid this.

The middle three stages are the most important to get right. These are the stages that bring the real value of the retro, and as such need to be thought about carefully and holistically during planning. When I first started running retrospectives I didn't appreciate the importance of this, and would often run three completely separate events that didn't take data from one stage to another. Sure, my retros looked great on paper, but in practice we would start each stage from fresh, ignoring the findings from the last.

These days my retros blend these three stages so that the data that is generated from the first part is analysed as we go and at the end deciding what to do is usually a no-brainer. This is the key benefit of running a retro using the five stage model over the death march variety; you can walk away from the retro knowing the thing(s) you are going to improve over the next iteration. I typically limit the team I'm working with to one improvement so that we have a high chance of succeeding with it. At the very most I would allow three improvements, but before doing so I have to feel confident that we're going to be successful at the improvements. If a team gets used to not delivering on the improvement they've identified during retro, then they'll stop believing in retrospectives, and if that happens then the retro is as bad as the death march retro.

The final stage of the retro should be the close out. I like to think of this as a little retro on the retro. The team will give you a feel for anything they liked or didn't like about the retro, and then you can use this feedback when planning the next retro. The team that I'm currently with love working with Lego and sticky notes, but they're not so fond of drawing. I setup any graphical things like a boat or a graph before they arrive, and then they use those as props to place their stickies on.

The book mentioned above has some great ideas for different parts of the retros. The best tool out there for planning five stage retros though is Retromat. I use it every time and we always have a blast of a session. Make sure you give yourselves plenty of time to run it. I find that three hours is a good amount of time so that the team doesn't feel rushed. After the retro I stick the item(s) that we're going to be working on to improve on the wall near the team area. This lets everyone know that we're committed to improving, and committed to the improvement we've decided to make.

No comments :

Post a Comment