The Agility of Apollo 13
An Interactive Training Exercise
by Jeff Himmelright
First published on 5 July 2016
I often associate the artistry of films to real life circumstances. If you have not seen, or it has been a while since you have seen, Apollo 13, directed by Ron Howard, please indulge. The movie, based on actual events, candidly captures what it means to be on a project that must quickly adapt to changes in requirements, prioritizing, and dealing with impediments.
In fact, when I conduct an orientation for project team members new to agile, or even for personnel curious to find out more about agile and scrum, I show a very brief video clip from Apollo 13 on YouTube? to set the stage for an interactive scrum coaching event. I would like to share this now.
During the brief video excerpt from the film, the NASA flight control team in Houston learns that the levels of carbon dioxide (CO2) are rising in the spacecraft and will soon be toxic. It is essential that they find a way to lower the level of CO2; otherwise, the three-man crew of astronauts may asphyxiate. The problem stems from the fact that they are forced to sit in the LEM module for the return flight home where the filters were meant to function for only two men for a day and a half. Furthermore, the more robust filters are in the other command module, where the astronauts cannot sit until just before re-entry.
“What about using the filters in the command module?” the Flight Director asks.
“The filters in the command module require square cartridges and these are round,” he is informed.
Another flight control member replies, “This just isn’t a contingency we’ve remotely looked at.”
The Flight Director responds, “Well I suggest you gentlemen invent a way to put a square peg in a round hole … rapidly!”
It is a brilliant sequence, which implies that the team is empowered to work the problem and that they cannot afford to wait around to be told what to do next. The next scene shows a group of rocket scientists (stripped of their traditional roles) gathered around a table with an emptied box of equipment and gear (the same that is available to the astronauts) with the marching orders to build a filter. It is pure prototyping time: no upfront documentation, no specifications, and no approval sign offs or change requests. The team needs to get busy building it – working collaboratively as a creative team.
After I show my group this short video, I usually point out the line: “This just isn’t a contingency we’ve remotely looked at.” I ask the group if this line sounds familiar? To this, I caution that we should not fault ourselves for not being able to foresee every single possible contingency. True, we may uncover some risks, but we cannot predict them all. It is the hidden unknowns that catch us off guard. This is one major reason why we embrace an agile approach – as stated in the Agile Manifesto – Responding to change over following a plan.
In my orientation, we discuss how the original business requirement (or vision) of the mission has changed. I ask them to identify the new high-level business requirement. Most often, someone will chime in with “Get the astronauts home – back to earth!” To this I respond, “Get the astronauts back home alive?” This dialog is a great way to introduce (albeit in an amusing way) how assumptions are often built into requirements, implied but unstated. Would a user story possibly solve this by using acceptance criteria?
The next step I ask is to help me write a user story for this specific problem we are trying to solve. Although the story varies from class to class, it typically emerges in the format, “As an Astronaut, I need a filter system to reduce the CO2 so that I can breathe and attempt earth re-entry.” Quite often, this exercise helps the group understand why we write a user story from the user (or beneficiary) perspective. For example, why don’t we write instead, “As a Flight Control Engineer, I need to prototype and build a CO2 filter, so that I can tell the Astronauts how to build it”?
In the next step, we create acceptance criteria, usually as follows:
- Astronauts report ability to breath better, and/or
- Flight control instrument monitor shows CO2 levels steady below dangerous levels.
The next step is to create some tasks. We could actually size the story first and then create tasks, but in my opinion, the group feels more comfortable sizing it after they understand their tasks. When I ask for tasks, I often get silence. This is not unusual. Many of them are thinking of logical steps in their heads and not blurting out the first task that comes to mind. But in time, we typically identify five to six tasks:
- Inventory items on spacecraft
- Build filter
- Test for air-tightness and functioning in the simulator
- Document the build process (steps) and installation
- Radio the astronauts and walk through steps
- Get feedback from astronauts and instruments
As each person offers a task, I have them write the task down on a post-it note with their initials. I try to get at least five different people, because, as they will soon realize, all who volunteered to identify a task will also volunteer to be on my scrum team. However, if an out-spoken person identifies multiple tasks, it is usually not difficult to get another member volunteer and self-assign a task.
At this point, it is time to size the user story: Reduce CO2 Levels. Relative sizing, however, requires something to be relatively compared to. So, as I hand out planning poker cards to my volunteers, I tell them about another story on the backlog: Fix Trajectory, the purpose of which is to modify the trajectory of the space craft so that it does not come in at an angle too steep and burn up in the earth’s atmosphere, or come in too flat and bounce off the atmosphere and fly endlessly into space. This story is an actual part of the movie as well, but I do not show it, I only explain it.
I then ask them to size the complexity of the Reduce CO2 Level story relatively compared to the Fix Trajectory story. Naturally, I get some confused looks. “What do I know about the complexity of fixing the trajectory compared to our story?” someone asks. The point that I tell them is that it is not important during this exercise for them to be experts at anything in rocket science (unless of course I was actually performing an agile orientation to a group of rocket scientists). The point is to consider both stories, make a decision, choose a number from the card deck, and then discuss with the team.
(Note: I limit the planning poker cards that I hand out to 1, 2, 3, 5, 8, 13, 20, and 40).
If you perform this exercise, you will get some compelling arguments from your team as to why one story is more complex than the other. I personally have no objective truth as to which would be more complex. In any case, the sizing dialog is usually provocative and fun.
After we discuss the negotiation of the complexity size, we usually enter into a discussion regarding the difference between relative sizing based on complexity and the inevitable question as to whether these numbers represent man hours. This confusion is common and deserves to be discussed. My opinion is NO, the complexity is not converted into man hours, but this article is not intended to break down that debate. Finally, the sprint planning is over and we are ready to move on to our daily scrum.
I invite my team up to the Scrum board and have them post their tasks under the New column near the pre-made story Reduce CO2 levels. In the interest of time and in an attempt to contain the extravagant imaginations that come from such teams during interactive events, I announce a two-day sprint. I base this on the video point that the astronauts have roughly 48 hours before their air becomes toxic.
Even the most experienced person cannot foresee every scenario that your team will produce, but it is important that you, acting as the Scrum Master, guide them to be self-directing and collaborative. Some teams try to organize the order in which they speak based on the logical order of which tasks need to be completed (e.g., we cannot build the filter before we inventory and gather the parts). But I typically inject probing questions, such as, we need to document the inventory as well, right?
The other important factor that comes out of this two-day* mock stand up (whether they save the astronauts lives or not) is that whoever has a task that is dependent upon another task to be started, cannot just say, “I have nothing to do.” Ask, “But what else can you do?” The answer will usually come quickly, “I guess I can help Jessica with the inventory and gathering the supplies.”
Yes! Now this is a performing team! The vast majority of my interactive trainings using this exercise drive home the message of what a motivated and self-directed team really means – to be collaborative, communicative, committed, caring, and creative. It is a fun exercise and I usually receive great feedback on it.
Naturally, the example I employ here is somewhat fanciful. The reality for many of my training participants is that their world requires them to create tasks that are not so easily identifiable, sometimes based on vague acceptance criteria. A real life example may help in their understanding of how to differentiate between a user story and a task and how to work with the Product Owner to write a better story with understandable and achievable acceptance criteria.
Nevertheless, the Apollo 13 Scrum exercise is intended for multiple audiences, it can be readily understood, and is really intended to drive home the message of team work; that is, breaking out of those skill-set silos.
I hope you found this article informative and perhaps entertaining. I also hope that some of you will try it yourselves during a training or orientation.
Best of luck in all your projects and in becoming agile!
* Note: The two-day daily stand-ups are fictitious two days where I pretend a second day has arrived. I do not actually hold a 2nd day of training for this interactive event.