Recently I was reading about the immense operations the D-Day landings on Normandy were. I believe I had heard that it took over a year or planning just for the event itself. This included many practices and mock invasions.
Here are some numbers, courtesy of http://www.ddaymuseum.co.uk
“On D-Day, the Allies landed around 156,000 troops in Normandy. The American forces landed numbered 73,000: 23,250 on Utah Beach, 34,250 on Omaha Beach, and 15,500 airborne troops. In the British and Canadian sector, 83,115 troops were landed (61,715 of them British): 24,970 on Gold Beach, 21,400 on Juno Beach, 28,845 on Sword Beach, and 7900 airborne troops.
11,590 aircraft were available to support the landings. On D-Day, Allied aircraft flew 14,674 sorties, and 127 were lost.
In the airborne landings on both flanks of the beaches, 2,395 aircraft and 867 gliders of the RAF and USAAF were used on D-Day.
Operation Neptune involved huge naval forces, including 6,939 vessels: 1,213 naval combat ships, 4,126 landing ships and landing craft, 736 ancillary craft and 864 merchant vessels. Some 195,700 personnel were assigned to Operation Neptune: 52,889 US, 112,824 British, and 4,988 from other Allied countries.
By the end of 11 June (D + 5), 326,547 troops, 54,186 vehicles and 104,428 tons of supplies had been landed on the beaches.”
Could Agile be used for a project this size?
The question that went through my mind is whether projects can be too large for Agile?
I would say some project characteristics make the project less suited for Agile, but it isn’t just about size. In fact, the two factors that can make a project suitable for Agile don’t involve size at all.
Perhaps two definitions would help. When I am referring to Agile, I am believe there are two main types of Agile:
Drunken Sailor Agile – This is where there is an un-estimated backlog of user stories and the stories are pulled from the backlog just in time for the next iteration. These projects may not have an overall budget. Frequently these Agile projects align their processes with Flow. This is where No Estimates methods and practices are used.
Budgeted Agile – This is where there is an initially estimated backlog of user stories and a budget for the overall project. It most cases the project also has a tentative schedule on what is expected when during the project. These projects are typically done by large enterprises and companies focused on being profitable.
The Two Factors
1) End Product negotiable – Drunken Sailor Agile works really well when the end product is negotiable or unknown. In those situations, the ability of Drunken Sailor Agile to pivot returns great value. But when the Minimum Viable Product doesn’t differ greatly from the Maximum Viable Product, the ability to Pivot returns less value. Capturing half the beaches on D-Day wasn’t acceptable. It really was an all or nothing value proposition.
2) Predictability/Co-ordination – Drunken Sailor Agile struggles to provide any level of predictability and co-ordination. If you require predictability, you really do need to use Budget Agile with a schedule. In many cases this predictability may not be about when the project is complete. Frequently the solution is so complex and intricate that dependencies between components requires much more predictability that Drunken Sailor Agile provides. The amount of co-ordination required on D-Day would prevent Drunken Sailor Agile from being used. Ships and Aircraft needed to be exactly where they said they would be.
As you may have surmised, I am not a hug fan of Drunken Sailor Agile. And I think the projects that it can be applied to are quite limited. I don’t think it can work on large projects.
More importantly, I don’t like Drunken Sailor Agile as I think it creates an “Us versus them” atmosphere. We seem to be scared to tell clients when we will be done in case we are wrong. It all comes down to trust and Drunken Sailor Agile seems like we want to be trusted without providing our trust that estimates and schedules will be treated fairly.
I’m still in awe of the co-ordination and trust required for the D-Day operations. Agile has a way to go before we can approach those levels.