>Finally, the overhead of creating and reviewing a design doc may not be compatible with prototyping and rapid iteration. However, most software projects do have a set of actually known problems. Subscribing to agile methodologies is not an excuse for not taking the time to get solutions to actually known problems right.
Here lies the biggest problem with the article. Most software projects _do not_ have a set of actually known problems. Agile exists precisely because it's hard to pin down what problems are, and you learn much more about your product with gradual experiments than with some grand, centralized design.
Unless you are totally certain about your solution, design documents don't have a place for most projects.
I don't agree with this viewpoint. Agile is about just-in-time design, not no-design.
At some point, you need to decide what the next increment you're going to build is. Before you write the code for that increment, you have by definition picked an actually known problem to solve, and for that you should write a design doc.
I think what you're objecting to is the waterfall concept that you would write a design doc that covers the whole project, rather than just designing what you're going to work on next. I can wholeheartedly agree with that objection.
However everything in the article is consistent with epic-level or story-level design. As the complexity and cost of change increase, more up-front design is appropriate. None of that is incompatible with the agile tenets of building small increments and delivering them often to make sure that they add value.
If you're lucky enough to be working in the early stages of a project with a few thousand lines of code, and little to no production data on which to maintain integrity, then the value of formal design docs goes way down. But it's important to know that you'll need them later.
In some sprints my team will write multiple design docs, though that's uncommon. For example, if we're building two new features, and each is self-contained. Those design docs are probably small.
In other sprints, we won't author any new docs, for example if we're implementing and shipping/demo'ing chunks of a large, complex feature for which we've already completed the technical design.
I'd suggest coupling design docs to stories/epics, not sprints.
While I agree, I find this common argument to have a faulty rhetorical approach. Leadership can often be allergic to allegations that there are problems that they don't know about. They can be outright defensive towards suspicions of uncertainty.
I feel there may be a better way to express the utility of rapid iteration and design-as-you-go without triggering a fight response.
Here lies the biggest problem with the article. Most software projects _do not_ have a set of actually known problems. Agile exists precisely because it's hard to pin down what problems are, and you learn much more about your product with gradual experiments than with some grand, centralized design.
Unless you are totally certain about your solution, design documents don't have a place for most projects.