You have a good point on your idea of "failing early waterfall". But this is an utopia. Waterfall project will never have the feature to fail early, it is not part of their DNA. With the lack of transparency brought by the tunnel effect, Death March project will always happen in Waterfall.
My two cents.
a) Large: This is were you might have a point. When your project is large - large because of functional design issues, or large because it needs to be large? - collaboration might less effective without a sort of strong portfolio governance (agile or not). All project is difficult when *big teams that never worked together before*. But on the other hand, does Waterfall have greater success on ad-hoc large teams? I would tend to say that we might have the same problem. I would hypothesis that most large projects fail, less because of the chosen methodology, but for cultural problems, requirement managements, lack of purpose that limits the collaboration and effectiveness.
b) Complexity: One great advantage with Agility is the facility to deal with complexe problems. By shorting the length of deliverables, working intensively on collaboration (small and large), and testing value early, agility can address complex and unknown problems. Agility is about "adaptation to change" needed in complex situation. By implementing fast feedback, and optimized transparency in the agile methodology, the Fail Often, Fail Fast, Fail Cheap principles are embedded in Agile.
c) Infrastructure: No project will succeed without its infrastructure, and the capacity for the development teams to deliver, integrate and test their components rapidly. Agility states that you need to test everything (the business value) as soon as possible, iso-production systems, in a cadence way. Waterfall states that you need to plan to have your machines, your testing machine on the right order. I don't see how Agility would create a insurmountable challenge in managing infrastructure.
The "adoption of agile" has nothing to do with this failure. On the contrary. The project was absolutly not agile. It was a bad waterfall project, date-driven, with a complete failure in requierements management, and lack of architectural ownership. There's no way a more waterfall approach would have saved this project. It would have killed it earlier. This is non-sense. A fixed date driven project, with a fixed + growing set of requirements is a nightmare to manage. It will necessary lead to much higher cost than planned.
The audit report is totally wrong to state that a cost-plus-fixed-fee was a bad deal for CMS. For what I read, it seems like an excellent deal for CMS. A cost-plus-fixed-fee is the cheapest way to build a product while you do not have the final requirements. The real problem I see while reading the audit report, is that CMS was totally incompetent to manage and communicate with their contractors (CGI and Accenture), and totally incompetent in managing the requierement portfolio backlog.
A fix-cost contract would have cost a lot more.
A more agile approach, a portfolio management structure like in SAFe for instance, continuous integration, continuous delivery and test, would have helped a lot.
Slashdot Mirror
You have a good point on your idea of "failing early waterfall". But this is an utopia. Waterfall project will never have the feature to fail early, it is not part of their DNA. With the lack of transparency brought by the tunnel effect, Death March project will always happen in Waterfall.
My two cents.
a) Large: This is were you might have a point. When your project is large - large because of functional design issues, or large because it needs to be large? - collaboration might less effective without a sort of strong portfolio governance (agile or not). All project is difficult when *big teams that never worked together before*. But on the other hand, does Waterfall have greater success on ad-hoc large teams? I would tend to say that we might have the same problem. I would hypothesis that most large projects fail, less because of the chosen methodology, but for cultural problems, requirement managements, lack of purpose that limits the collaboration and effectiveness.
b) Complexity: One great advantage with Agility is the facility to deal with complexe problems. By shorting the length of deliverables, working intensively on collaboration (small and large), and testing value early, agility can address complex and unknown problems. Agility is about "adaptation to change" needed in complex situation. By implementing fast feedback, and optimized transparency in the agile methodology, the Fail Often, Fail Fast, Fail Cheap principles are embedded in Agile.
c) Infrastructure: No project will succeed without its infrastructure, and the capacity for the development teams to deliver, integrate and test their components rapidly. Agility states that you need to test everything (the business value) as soon as possible, iso-production systems, in a cadence way. Waterfall states that you need to plan to have your machines, your testing machine on the right order. I don't see how Agility would create a insurmountable challenge in managing infrastructure.
The "adoption of agile" has nothing to do with this failure. On the contrary. The project was absolutly not agile. It was a bad waterfall project, date-driven, with a complete failure in requierements management, and lack of architectural ownership. There's no way a more waterfall approach would have saved this project. It would have killed it earlier. This is non-sense. A fixed date driven project, with a fixed + growing set of requirements is a nightmare to manage. It will necessary lead to much higher cost than planned. The audit report is totally wrong to state that a cost-plus-fixed-fee was a bad deal for CMS. For what I read, it seems like an excellent deal for CMS. A cost-plus-fixed-fee is the cheapest way to build a product while you do not have the final requirements. The real problem I see while reading the audit report, is that CMS was totally incompetent to manage and communicate with their contractors (CGI and Accenture), and totally incompetent in managing the requierement portfolio backlog. A fix-cost contract would have cost a lot more. A more agile approach, a portfolio management structure like in SAFe for instance, continuous integration, continuous delivery and test, would have helped a lot.