With all the speculation on what went wrong with the ACA site and all the agile pundits making statements about how agile could have saved the site, here's some actual facts beyond all the opinions - that Daniel Patrick Moynihan would remind us...
Every man is entitled to his own opinion, but not his own facts
and
The Key Findings are
- Oversight weakness and lack of adherence to planning requirements.
- Acquisition planning carried high levels of risk.
- Requirements for developing the FFM were not well defined.
- Contract type carried risk for the government.
- New IT development approach was supposed to save time, but carried unmitigated risk.
- Contractor did not fully adhere to HHS procurement guidelines, missing opportunities to capture and consider risk important to program success.
- Changing requirements and oversight contributed to significant cost growth, schedule delays, and reduced capabilities.
- Unclear contract oversight responsibilities exacerbated cost growth.
- Significant contractor performance issues without corrective actions.
So when we hear
Think in what domain, with what value at risk, with what complexity of project, and what business process in which these could possibly be applicable. In fact this goes back to the core of the agile manifesto. And when we hear "pure agile," Scrum Masters produce Scrum Slaves, Mob Programming, "we all want a seat at the table with equal voices, and many other "opinions," remember Moynihan and ask for facts, domain, past performance, experience, and examples of success.
As agile starts to scale to larger domains and the government seeks better ways to develop software beyond the failed processes described above - what parts of this manifesto are applicable outside of a small group of people in the same room with the customer directing the work of the developers?
As my colleague (former NASA Cost Director) reminds our team if you see something that doesn't make sense - follow the money. In the case of ACA and in the case of the Work Shop outcomes above.
