Wow, massively flawed premise here. 1. Using user stories to define your requirements does not make your process agile, just like writing a traditional require

Wow, massively flawed premise here. 1. Using user stories to define your requirements does not make your process agile, just like writing a traditional requirements doc does not make your process waterfall. It's not about the tools. If you're not capturing the requirements you need to capture, your process is just broken. 2. Design documents do not magically make your project successful. Agile doesn't like design documents because it typically uses more lightweight artifacts to capture design decisions--but it still captures them! Again, if those decisions are not captured at all, your process is broken. 3. Wat? Asynchronous vs. synchronous is a project design decision; how does this demonstrate the failure of agile methods? Multiple sources ([1], [2], etc.) have reported that the requirements for the system were not known until Spring of this year, and that they were in flux until weeks before the release. That's not a problem that would be fixed with use cases, UML and design documents. [1] http://www.nytimes.com/2013/10/13/us/politics/from-the-start-signs-of-trouble-at-health-portal.html?pagewanted=all http://www.nytimes.com/2013/10/13/us/politics/from-the-start... [2] http://www.huffingtonpost.com/2013/10/22/obamacare-website-programmers_n_4141411.html http://www.huffingtonpost.com/2013/10/22/obamacare-website-p...