Comment by alemanek

Specs weren’t the problem with waterfall. The difficulty in changing them to match reality was.

The waterfall process I experienced went like this:

- Product folks created requirements

- architects produced detailed specs

- project managers created tickets based on specs

- lengthy estimation ensued.

- Then finally developers proceeded with implementation.

- QA tested it.

Each step above involved lengthy review with like 5-10people. If the devs found an issue with the spec or god forbid the requirement it triggered a massive cascade of work for everyone above. Things needed to be reviewed again, customers may need to get contacted, …etc.

I think we can learn from that and optimize for change. Specs as living documents close to the code should be less cumbersome. But, just like anything else large corporations will probably fumble this like they did with “agile” (SAFe I am looking at you).

This is a long way to say specs aren’t bad. Specs that are difficult to change are though.