Create tangible retrospective actions

In my view, the drive to inspect and adapt is the most important concept to have been popularized by the agile software development movement.

It’s an idea that got me hugely excited and engaged in the subject when I first came across it in 2005. This essence of this is that ‘we will always know more about the project in the future than we do right now’. The responsible response to that is to build in regular, frequent feedback mechanisms to our development process to be able to take stock of, and respond to, our improved understanding of the domain, technology, codebase, processes, practices and team.

In my head this is always represented with the following diagram. Where the blue dotted line indicates the original direction we thought was going to be right for the project (or codebase, or process, etc), the black dots represent reflection points, and the green lines represent the course corrections that were taken to improve things. At the end of the project, we ended up with a product or a way of working that we would never have envisaged at the start.

This is why I am such an advocate of having regular, frequent retrospective meetings throughout the course of a project, as they provide these important points of reflection and course correction. However, Retrospectives are only as valuable as the improvements they instigate. Sometimes, even though a team may have identified the right area of their project/process/codebase to improve, the corrective actions they decide on may fail to have a discernible effect. For example, a team may want to introduce a weekly customer support rota because the entire group is feeling impeded by the number of support requests being received.  This rota is drawn up and is respected for the first week, so things start to seem better. Beyond that first week though, there’s a good chance the rota will start to get forgotten and the problem will return.

Corrective actions that are destined to succeed often have a tangible effect on, or introduce a new artifact to, a team’s day-to-day life.  In my example, the support rota is much more likely to become entrenched if there is a visual token reminding people every day that it exists and is something they agreed to do. In my team we’ve done this by placing a big picture of an ogre on the desk of the person on rota duty.

When a support request comes in, there is no debate about who’s responsibility it is to ensure the request is handled.  More importantly, the fact that our ‘Support Princess’ token is so big and unappealing means that when a team member’s turn on the support rota is over, they are very quick to hand the duty onto the next person, and the rota cycle continues.

Plus, there is something strangely satisfying about placing a silly picture of an ogre on your colleagues desk.