Death Stars and the importance of the retrospective
Having recently watched the second new Wars film ‘The Last Jedi’, I’ve had Star Wars on my mind until my thoughts turned to retrospectives — As they so often do.
The Empire, now the first order have lost three plant killing weapons. Two space stations and now an entire planet, and I think it’s fair to say there are some similarities.
To re-cap.
‘Death Star 1’ gets blown up by Luke Shooting a torpedo into the exhaust system which starts a chain reaction and blows up the entire station. Essentially exploiting a systemic structural weakness in the station, and creating a chain reaction.
‘Death Star 2’ gets blown up by Lando Calrissian shooting the main reactor, which causes a chain reaction which blows up the whole station, eg. exploiting a systemic structural weakness, and causing a chain reaction.
‘Star Killer Base’ or ‘Death Planet’ get’s blown up by taking advantage of a systemic structural weakness, which causes a chain reaction, which… blows up the whole base.
…I’m seeing a pattern emerge…
Although all of this happens in a galaxy far far away, I think there are some things worth taking from the story.
It’s Star Wars, so, alright, but otherwise, single points of failure, 0 redundancy systems, and not learning from mistakes. In this instance not thinking about modularising your super weapons, and handling your dependencies properly.
But back to retrospectives.
The Empire hits a problem. Their main plan get’s blown up, and instead of considering options they immediately begin the development of a second Death Star.
Which is susceptible to exactly the same fundamental issues.
When it happens in Star Wars, it seems fine, because it is a galaxy far far away, but how often do you actually see this sort of behaviour in day to day operations of companies?
Something goes wrong in the plan, but instead of taking a step back to understand and solve the root cause, the organisation continues to grind the same furrow. Either because there is no real appetite for change, or because sufficient time, resource and dedication are not applied to seeing a solution through. The same issue occurs and the cycle starts over.
Agile has a mechanism to avoid this in the form of retrospectives.
A retrospective (or retro), is a meeting held at regular intervals (Once a sprint generally) to talk about what could be improved.
This means talking about the root cause of what went wrong and solving or mitigating it.
Now, if after Death Star 1, the Empire had held a proper retrospective, how might things be different?
If I’m holding the retrospective, I’ll start off by brain storming the things that we can improve. I never use ‘what went wrong’, always ‘things to improve’.
Once, we’ve got a list, we’ll pick the biggest issue, and do 5 why analysis often with a Fish Bone or Ishikawa diagram. I find one issue at a time is enough, we’re looking for 1% improvement a day, we’re not trying to boil the ocean.
If we’d taken this approach with Death Star 1, how might this retro have gone?
What could have gone better? — Well, the Death Star could have not, been blown up. Under the circumstance I think, it’s clear that, that’s our biggest problem.
Ok, so why did the Death Star get blown up? (Why number 1)
Well, there, was a chain reaction inside the Death Star.
Why was there a chain reaction inside the Death Star, (Why number 2)
Well, Luke Sky Walker fired a torpedo into the exhaust pipe.
Why was Luke able to fire the torpedo in the exhaust? (Why number 3) - (I’m going to ignore the Rogue One revelations for now.)
Someone did not check the design completely for weaknesses.
Why were the designs not checked? (Why number 4)
I’m just guessing here, but rushing to hit a deadline?
Why were we rushing to hit a deadline? (Why number 5)
Again, guessing, but, Fear of being force choked?
At this point, we should have a viable root cause, eg. a root cause that we think is plausible and likely.
Just asking why and putting down the first thing that comes to mind, isn’t all that helpful. Think of all of the possibilities and pick the most realistic or the most appropriate.
For instance, here, for item 3, we could have asked why Luke Skywalker fired a torpedo into the exhaust. It would have been a legitimate question and would have lead us to a root cause. Most likely people being pissed off with the Empire.
This just shows if you have two people they may well come up with different answers, most problems have more than one cause, but let’s deal with one thing at a time.
To use our example above, our root cause analysis identifies that people were too busy trying to get things done, rather than concentrating on quality. Our assumption is that is was done out of fear.
Based on circumstances we could also conclude that there was not enough time allocated for the project to be delivered, insufficient analysis, insufficient resources or 40 things based on the circumstances at the time.
The idea though, is to identify a likely root cause in your circumstance and address it.
To use our example. People were too afraid to speak up about the fault or too afraid to ask for more time to solve the issue. This does assume that the people working, want to do the best job possible and so on, but we’ll skip that for the moment.
How do we solve a fear issue in the organisation? — Well maybe, do less of the public shaming and or less public capital punishment?
— You know, start small.
Ideally make the change measurable, eg. For instance how many Empire members of staff, were summarily executed last week, and how many this week?
It gives you a measurable performance that you can track over time, to see how you’re improving.
Ultimately the idea is to make sure that you don’t keep on making the same mistakes, and that you can grow and develop. Getting 1% better everyday or every sprint can really make a difference, and proper root cause analysis of problems is a big part of that.
Having continuous improvement baked in, is one of the key parts of agile, and it seems that if Darth Sidious had an agile coach who he didn’t force choke, the Empire might have just won.
Use these tools for good, not to build death stars.
