Smith & Sidky’s Becoming Agile in an Imperfect World opens with a description of the Quecreek mine rescue as a metaphor for Agile software development. They identify elements of the rescue team’s efforts that are shared with Agile development. Those elements include the presence of time constraints to the work (see Newspaper Production as a Metaphor for Software Development for analysis of the example used), the need to establish and follow priorities, expecting and embracing change, and collaborative teamwork. I think the same could be said of a host of different human activities but whether that establishes them as reasonable metaphors for Agile software development is less certain.
Unexplored with this metaphor are the ways in which disaster response differs from Agile software development. Unlike disaster response, which is often an all-out, round-the-clock activity, software development is intended per the 8th Agile Principle to “Maintain a sustainable working pace.” In the case of the mine rescue, deadlines were not known in advance and were themselves subject to review and change throughout the process. Agile software development typically works with pre-specified work deadlines as a means of creating focus on delivery and tends to resist changes to those deadlines (e.g., rarely, if ever, changing sprint duration during a sprint in Scrum). Finally, while the focus of Agile software development is to create a reusable product, disaster responses typically make no effort to create reusable processes or products, focusing instead on resolving the immediate threat to people or valued assets with the expectation that reusable learning will follow in retrospective reviews. And, of course, those retrospective reviews are very different from Agile retrospectives in scope and scale (e.g., weeks of Congressional hearings following the Challenger disaster).
Of the software systems activities I have been part of, I think the one most closely parallel to the mine rescue would not be software development but rather efforts to deal with production software issues and outages, especially in the context of mission critical systems. In addition to the common elements identified above, those situations also are characterized by the elements where the mine rescue differs from software development, being all-out, round-the-clock efforts, evolving deadlines, and focus on getting the system service functioning by any means necessary with the expectation that long-term solutions and reusable elements can be created later.
