J I McFadyen Engineering

Supporting Collaboration

Incident Retrospective

I’ve spent the last few days on the Cognitive Edge practitioners training course. One of the exercises was to use all the methods to design how to tackle a complex problem one us the group presented.

Well, I couldn’t miss an opportunity for free consultancy.

The problem

House with old picture

Looking Back to the Past via artsytime.com

Recently the team went through a bad patch. Failed deployments, increase in live incidents. All unusual for the team. This was the problem I put forward (or something along these lines):

A lessons learned workshop for a team that has failed to meet either it’s, or it’s managements, expectations in the last live release. In particular, the environment must focus on actions to take from the experience rather than assigning blame to individuals.

The interesting things was that, as a team of 5, only 2 of us knew anything about software development. We had 2 business consultants and a GP to help. They weren’t aware of Norm Kerth‘s book or Diana Larsen and Esther Derby‘s. No prior knowledge of retrospectives or anything similar.

I’ll let you make your own decisions on whether this had a positive or negative effect on the plan.

The plan

So, we needed to use some, but not necessarily all, of the techniques that had been introduced over the course to tackle the problem.

After discussion we settled on the following format (the greatest value was in the discussion though):

  1. Future, backwards: by splitting the team (of roughly 30) up into small groups we could gain several insights into the sequence of events that lead up to the series of problems we’d just lived through. Also, a very key point was that the exercise only deals with facts and fantasy, a safe way of surfacing what happened without blame.
  2. Anecdote circle:  by comparing the future, backwards models of the various groups we would be able to extract the significant turning points of the time frame and ask deeper questions about those. These anecdotes could then be examined and the influences and values brought out.
  3. Introduction to Cynefin: to move the workshop on we would then need a simple overview of Cynefin. Nothing fancy or long, just the basics. Like Dave Snowden’s Children’s Party video.
  4. Contextualising framework: the values and influences that emerged during the anecdote circle are mapped to the Cynefin framework to make sense of how they can be addressed.
  5. Safe-fail probes: simple, short experiments to see how we could affect key areas in the team to help prevent the problem coming up again. Or, at the very least to give us an indicator that we may have a problem. There was discussion around using another technique, Ritual Dissent/Assent, to make the probes more robust, but with the time frames we’re talking about (a week, maybe two) the effort didn’t feel worth the benefit. I think it is still something to keep in mind though. Particularly if the experiments are longer running or expensive.

It wouldn’t be a quick retrospective, but for something as serious as a productive team suddenly going off the rails I feel it would be time well spent.