Retrospiketives

I’d like to introduce and encourage a new agile activity or ceremony:

Retrospiketive [retro-spike-tive] – A time boxed meeting spawned from a retrospective to focus on a single change implementation plan. Also called a “Spiketro” for short.

The name pretty much says it all to anyone already immersed in agile software development. It’s a happy marriage of two existing agile concepts, namely:

Retrospective – A time boxed meeting held at the end of an iteration, or at the end of a release, in which the team examines its processes to determine what succeeded and what could be improved.   – Agile dictionary

Spike – A story or task aimed at answering a question or gathering information, rather than at producing shippable product.  – Agile dictionary

A “retrospiketive” fills the gap between improvements identified in retrospectives and the change in behaviour or reality needed to realise the gains. Gains ultimately in team productivity and throughput of value to the business and customers.

Retrospectives vary in format but usually seek to scrutinise the past and determine, as a team:

  • what we should keep doing
  • what we should stop doing
  • what we should start doing

The latter two points involve a change in behaviour and so require determination and effort. It’s not uncommon for a retrospective to generate a multitude of different suggestions. All well and good (assuming good retrospective practice and all team members get to speak and speak freely).  However, the challenge becomes translating these ideas into actions and following up after the meeting to make something happen, to make a difference.

It’s wise at this point in the process to pick a single action point which the team believes will make the biggest positive impact on the team’s performance. If teams are voting on each other’s suggestions in the retrospective (a common practice) this may already be clear. At the very least, the team should then aim to implement this one change.

This is where a “retrospiketive” can come into play. For example, let’s say the team chose “Start doing: make User Stories more well defined and smaller in size”. The team believes this single improvement could reap the most benefit out of all of the points made in the retrospective. Members of the team are likely to need to spend some time focusing on making this happen. Perhaps one person (a BA,  PO or Coach) needs to do some research and put forward a recommendation to the team on best practice for User Stories. Perhaps the team holds a workshop on writing good User Stories? This may then result in the team agreeing and producing a template for a User Story with a guideline for appropriate sizing and when a User Story should be split.

At the moment there is no standard vehicle for supporting such activity. A “retrospiketive” is a time boxed meeting that focuses on a single area of team performance improvement. The “spike” emerged as a means to support research and information gathering to inform and support the work to build a shippable product. Likewise, a “restrospiketive” sits outside of the direct work of building a product but indirectly provides value to that product by way of reduced cost, reduced time or perhaps a greater product.

If a retrospective is a searchlight making areas for improvement visible then a retrospiketive is a laser with a sharp focus on one point of improvement.

A retrospiketive should involve the whole team where appropriate or involve a smaller working group. If the latter, every team member should have the opportunity to form part of the working group and therefore attend the retrospiketive.

A retrospiketive should be high energy and last for half an hour or so. The aim of the meeting is to keep the momentum going from the retrospective and tackle head-on the identified item of change. The meeting may be used to:

  • conduct research (everyone brings a laptop)
  • agree what change is actually desired or needed and why it is important
  • generate ideas for making the change happen
  • produce an change plan with individual actions

Not all changes will need a retrospiketive, for example, if the action or actions to implement the change are already clear coming out of the retrospective meeting. However, if the change implementation needs to be better understood by the team and the team needs to formulate a precise action plan then a retrospiketive may be just the ticket. Note that there is nothing to stop the team spawning another retrospiketive either as a follow up to complete or to focus in even more narrowly on an area of interest.

An Example

In one of my teams over the last few months, a recurring area of concern in iteration retrospectives was the way we conducted standups. We knew we had two many people (16) and that we often ran out of time. Also, we had so many initiatives, each with many User Stories in flight at any one time that we ended up looking at several Kanban boards. There also seemed to be a lot of repetition from day-to-day since the type of work meant some areas moved quite slowly and little had changed. We tried varying the format from Scrum-style round the table (yesterday, today, blockers) to Kanban focus on User Stories travelling across the boards. Neither really nailed it. The team size was a factor but for other reasons we could not change the team size in the short-term.

The breakthrough came when we had a “retrospiketive” (although we did not call it that at the time – the name came in hindsight). In this meeting we focused on this one thing, namely how do we make standups provide more value to the team and ultimately to our products? We broke the meeting down into areas of thinking:

  1. why – why should we do daily standups?
  2. what – what do we need to change?
  3. how – agreed format for the standup going forward (i.e. identified the changes)

The first point, “why” was deemed important as this (a) double checked they are worthwhile, and (b) as a result of this it strengthened our resolve to make a difference (we all agreed they were important and why).

The second point generates agreement on “what” needs to change.

The third point generates agreement on “how” we will make the change happen.

This is not a prescription for a retrospiketive, just as there is no single prescription for a retrospective or spike. However, in this example it proved to be very effective. In fact, the retrospective proved to be more effective in making a change than all of our retrospective for the previous few months.

I hope you find retrospiketives an effective and fun vehicle for positive change in team performance.

Have you tried something similar? Do you have any other suggestions for getting the most out of retrospectives?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>