I often associate the artistry of films with real-life circumstances. If you have not seen Apollo 13
, directed by Ron Howard (or if it has been a while), 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 and prioritizations, while 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 clip from Apollo 13
on YouTube to set the stage for an interactive Scrum coaching event, which I would like to share with you.
Square peg in a round hole
During that brief film excerpt, 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, for the return flight home, they are forced to sit in the LEM module, where the filters were meant to function for only two men for a day and a half. The more robust filters are in the other command module, where the astronauts cannot sit until just before reentry.
"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 up-front 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 training class 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. I caution that we should not fault ourselves for not being able to foresee every single possible contingency. True, we may uncover some during a risk analysis, 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) has changed. I ask them to identify the new high-level business requirement, which is really a no-brainer. Often, someone will chime in with, "Get the astronauts home — back to Earth!" To this I respond, "Get the astronauts back home alive
?" This dialogue 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?
Differentiating between a user story and a task
Next I ask the team to help me write a user story for the 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 reentry." Quite often, this exercise helps the group understand why we write a user story from the user's (or beneficiary's) perspective. For example, why don’t we write, "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" instead?
In the next step, we create acceptance criteria, usually as follows:
- Astronauts report the ability to breath better.
- Flight control instrument monitor shows CO2 levels steady, below dangerous levels.
The next step is to create some tasks. We could actually size the user 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 the spacecraft.
- Build the filter.
- Test for air-tightness and functioning in the simulator.
- Document the build process (steps) and installation.
- Radio the astronauts and walk through the steps.
- Get feedback from astronauts and instruments.
As each person offers a task, I have them write the task 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 outspoken person identifies multiple tasks, it is usually easy to get another volunteer and then have them self-assign the tasks.
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 spacecraft 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 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 relatively size the complexity of the Reduce CO2 level
story 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, make a decision, choose a number from the card deck, and then discuss with the team.
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 dialogue is usually provocative and fun.
After teaching the negotiation of the size and explaining the difference between relative sizing based on complexity to the inevitable question as to whether these numbers represent person-hours, 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 ScrumMaster, 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 these two mock daily stand-ups (whether they save the astronauts' lives or not) is that whoever has a dependent task (one that is dependent on another task in order 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 with gathering the supplies."
The two daily stand-ups are over a fictitious two days; I pretend a second day has arrived. I do not actually hold a second day of training for this interactive event.)
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 it is really intended to drive home the message of teamwork — 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!