Was the Manhattan project an Agile project? I actually think it was, but you have to broaden your thinking about how you define “Agile” in order to see that. Some people have a very narrow definition of Agile:
- To some people, Agile equals Scrum and if you’re not doing Scrum and doing it “by the book”, you’re not Agile
- To other people, Agile means going fast, empowering teams, or any other attributes and ceremonies typically associated with Agile/Scrum projects
What Does” Agile” Really Mean?
I have a much broader view of what Agile means. Substitute the word “adaptive” for “Agile” and it will be a very close fit. Agile is a mindset best suited for two types of projects:
From that perspective, I think the Manhattan Project can be considered to be an Agile project.
- Projects that have a high level of uncertainty that call for a flexible and adaptive approach to find a solution. (This kind of project does not lend itself well to a traditional, plan-driven project management approach because it is very difficult, if not impossible, to develop a detailed plan upfront for a project with a high level of uncertainty
- Projects that require a high level of creativity and innovation to find a solution. An over-emphasis on planning and control often found in a traditional, plan-driven project can stifle creativity and innovation
Manhattan Project Summary
Here’s a brief summary of the Manhattan Project:
“The Manhattan Project was a research and development undertaking during World War II that produced the first nuclear weapons. It was led by the United States with the support of the United Kingdom and Canada. From 1942 to 1946, the project was under the direction of Major General Leslie Groves of the U.S. Army Corps of Engineers. Nuclear physicist Robert Oppenheimer was the director of the Los Alamos Laboratory that designed the actual bombs.”
“The project expenditure through 1 October 1945 was $1.845 billion, equivalent to less than nine days of wartime spending, and was $2.191 billion when the AEC assumed control on 1 January 1947. Total allocation was $2.4 billion. Over 90% of the cost was for building plants and producing the fissionable materials, and less than 10% for development and production of the weapons.”
“A total of four weapons (the Trinity gadget, Little Boy, Fat Man, and an unused Fat Man bomb) were produced by the end of 1945, making the average cost per bomb around $500 million in 1945 dollars….Overall, it was the second most expensive weapons project undertaken by the United States in World War II, behind only the design and production of the Boeing B-29 Superfortress.”
https://en.wikipedia.org/wiki/Manhattan_Project
You can find more details on the Manhattan project at the following location: Manhattan Project History.
Why Was The Manhattan Project Agile?
It seems strange to think of the Manhattan project as an Agile project:
- The Manhattan Project employed many thousands of people. it wasn’t a typical small team effort, and it took a long time to complete
- It had none of the normal attributes and ceremonies associated with a typical Agile/Scrum Project
- It was full of some very high risks for nuclear hazards and security breaches and had to have some fairly tight management
- It also took place at least 40-50 years before anyone knew anything about Agile as we know it today
So, why would you consider it to be “Agile”?
- It had a high level of uncertainty. When the project started no one had any idea of how long it would take, how much it would cost, or how it would be accomplished. It would have been virtually impossible to develop a highly-detailed plan for a project with that kind of uncertainty upfront. A flexible and adaptive approach was clearly needed. It also called for an incremental and iterative approach to try to find a solution.
- It required a lot of creativity and innovation. Developing an atomic bomb had never been done before and no one was really sure that it could be done at all
- There was a limited amount of planning and control. This effort was considered so important to winning the war that the project was essentially given a “blank check” to get it done
Overall Summary
I am frequently asked for examples of applying Agile to non-software projects. I think this is another good example; however, I think it shows that applying Agile to non-software projects requires some “out-of-the-box” thinking about Agile:
- Agile is not limited to Scrum. In many cases, applying Agile to non-software projects primarily involves adopting an Agile mindset
- A pure Agile approach is not always the only way to do a project. Agile can be blended with some level of project management to create a hybrid approach. You have to fit the methodology to the nature of the project rather than force-fitting a project to some kind of canned methodology
Related Articles
Check out the following related articles on “Agile Non-software Projects”:
- What Is Value-driven Project Management?
- What Can We Learn from the OceanGate Tragedy?
- What Happens to Professors If No One Signs Up for His/her Class?
- How Long Should I Study for PMI-ACP?
- What Happened to Southwest Airlines?
- Is Elon Musk a Good Agile Manager?
- Is There a Project Manager in Scrum?
- What is “Hyper Agile”?
- What Does It Take to Become a Good Project Manager?
- What’s Different About PMBOK Version 7?
Additional Resources
Resources for Agile Project Management Online Training.