One of my sessions at Agile Cymru gave different workshops and exercises that were great for teams at different stages of their life cycle. I talked about workshops for helping new teams feel comfortable and productive together. I also talked through an exercise as an idea how to deal with team members who don’t seem to ‘fit’. The last section was about workshops or exercises to grow a good solid team into a great team.
I have written about many of these workshops and exercises before (here’s a link to what I covered which also has links to write ups for the ones that exist). The last one I talked about – the ‘Death Sim’ – was so new I haven’t even implemented it yet!
The reason we haven’t implemented it yet was due to our imminent (now very recent) office move. We intend to experiment with this idea in the coming months, and I am so excited about the idea that I shared it as part of my talk. Since then, I’ve had so many people tell me they love the idea I thought I’d write it up, and add it to the list.
The idea of the rather morbidly named ‘Death Sims’ came to me when I ready Commander Chris Hadfield’s book. In it he describes some of the many ways that NASA prepares their astronauts. The bit that caught my eye was how they train to adapt to unexpected situations that are evolving & change rapidly. (If you haven’t read the book, do so, its great!). One incarnation of these are known at NASA as ‘Death Sims’. In these, it is often the case that one or more of the astronauts in these simulations either dies or becomes gravely ill, hence the name.
The game goes like this:
The astronauts turn up for work, and are handed a card.
The card might say ‘Chris has had an unfortunate accident and can’t now use his right arm’ or it might say ‘Joe has died from ammonia poisoning’.
From that moment on, the astronaut needs to talk and behave like this is the case. And it’s not just the astronauts who get to play – mission control do too. They suddenly find Astro Fred reporting on Astro John’s untimely demise. Which is where it gets interesting. Astro Fred wants to know what they should do with the body (they are on the International Space Station after all). Are there are any contamination risks the remaining crew need to worry about?
To illustrate: they may say the deceased’s partner is out of mobile phone range on a hiking trip, so they need to physically send people to talk to them. Or that the media have got wind of this, and mission control must make some kind of statement. Or that journalists have turned up at the school the deceased astronaut’s children attend, what should be done and by whom?
You get the idea. Rapid problem solving on the fly.
So What Problem Am I Expecting To Solve?
I know from my own experience that teams with good habits are successful. We know that good things happen when a team commits to test-driven development, SOLID principles, pair working, Definition of Done, low WIP limits etc. Many good teams commit to these things. Intellectually they know they are a good idea….but…..
“Just this ONE story couldn’t have automated tests written.”
Or “just this ONE story didn’t need pair working as it was just so small it wasn’t worth it”.
Or (my personal ‘favourite’), “I USUALLY only work on one thing at a time, but I knew these 3 stories were all working in the same area so it made sense to tackle them together”.
A GREAT team does these things because its habit. It’s just what they do. Every day, every time. On the other hand a GOOD team USUALLY does these things (that intellectually they know are great, just… habits are hard to form!)
Teaching a ‘good’ team how and where they could focus some attention to improve can be difficult. They may well be in denial that there is a need for them to improve at all. Its about stressing a system in a controlled way to see where it is likely to fracture first.
Enter the Death Sim.
I see it working like this.
Several teams are selected and from these, a single team member is identified. I feel its always good to pick these first people to deliberately cause maximum pain. Maybe that’s just me though…!).
These people are the (un)lucky recipients of the ‘Bang! You’re dead!’ cards. Give them literally just 5 mins to close down their PCs and vacate their desks. Even better if you can do this as they arrive in the morning, before they even boot up.
Caveats here would be that the product owners and wider business need to understand there may be some disruption for the duration of the game. I suggest more than a couple of days, as it can be easy for a team to paper over the cracks for short amounts of time. I feel a week minimum is probably a good start, although I’d like to see how a team manages for 2 weeks personally.
If you explain this is a way to identify improvements needed, the product owners and wider business should be persuaded to play the long game and sacrifice a team member for a sprint. After all, that team member could quite easily have gotten chicken pox or something similar in real life and be out of action anyway. Without the benefit of identified improvements at the end of it!
Now, so that this isn’t viewed as a punishment, the ‘dead’ people need something really fun to do. This will very much depend on your own company and culture.
Perhaps they could work on a business-led hackathon / prototype idea for 2 weeks. Perhaps they could pick something of their own, as a small, temporary team. Hackathon time is much-loved at NewVoiceMedia, which is why I have used that as an example.
But here is where the magic happens.
The teams themselves are now each down a team member.
- If they, & their missing team-mate practised pair working, there shouldn’t be too much problem working out where the work is up to and finishing it off without ‘the dead guy’.
- If their culture is to check code in often, then there shouldn’t be a big chunk of work that is inaccessible – all but the very last bit at worst should be checked in.
- How closely do developers and testers work? If the tester is now playing ‘the dead guy’, do the rest of the team know how to continue with out her/him?
It’s very easy to know what is good practice.
It’s also easy to commit to doing what you know is right.
But…. human brains are tricky things. Habits are hard to break (the bad ones) and hard to form (new ones). We are also world class at deceiving ourselves where our intentions perhaps don’t meet our behaviour.
As a Scrum Master, telling a team you observe they don’t always do the things they say they will is not effective. Especially if there is any way they can include the word ‘usually’ in their answer! This is not because they are rubbish by any means, it is because they are human.
I think death sims, whilst a bit morbid on the surface, are a great mechanism for shining a light into the dark corners of our working practices. Telling people what you think needs fixing is never as effective as them learning it for themselves.
I would love to know if you have tried anything similar – or if you decide to try this one! Let me know in the comments, or on twitter. Perhaps post a write up about what you did and how it went on linked in – make sure you share it with me!
(PS No astronauts or team members were harmed in anyway during the making of this activity).
Update: I have had some lovely feedback from @antonymarcano about this idea. He pointed out that it would be a lot less morbid if it didn’t focus on replicating the death of a team member! I can see how some might be queasy about that ;). Instead, he proposes, how about saying they’ve won the lottery and are taking an indefinite holiday? Much nicer and friendlier idea, so thanks for that Antony 🙂