What I worry about are where are the final documents that describe what the software does? That seems to get lost in Agile. And is sooooo important for long term maintenance, Technical Support/Call Center and years later Product Owner updates.

Today documentation is “Not Agile” and I question that. Before Agile if you had a real requirements management tool (we used DOORs) there were requirements, developers would look at the DOORs specs (linked to our internal task tracker for any new feature), during development they’d give feedback if they needed DOORs to be updated (it was fast, real-time, agile), QA would test against the tracker and DOORs and we then knew the DOORs specs accurately reflected what the code did. What a timesaver for Tech Support (the Call Center), PMs and others to know what’s in the code without having to go back to the developer. Without specs you seem to loose that.

Not the waterfall design docs Agile eschews that are in Word and get out of date before the code is delivered – but real information somewhere like in DOORs that says what the product is doing. Information the developers worked from and that QA says is how the code works.

So while I’m totally on-board with the Agile concepts for the software development itself, what is the answer for the rest of the company to know what’s in the code? Are we back to having to have the software developers go look at the code and tell them? Stories in tools like Rally are for the current release. And Agile doesn’t say how to update them or what happens for the next release. Agile “Stories” are incremental. After two or three releases, where does someone go look to see what the code does – other than asking developers? (which is a waste of their time).

That’s one of the big problems we’re hoping to solve or facilitate with Software 2020.