Disagree on the implication that the kanban flow (which is essentially what he described by moving stories between different phases) is inherently a waterfall;

Disagree on the implication that the kanban flow (which is essentially what he described by moving stories between different phases) is inherently a waterfall; it is in as much as the idea that a project is expected to be completed (or at least reach feature completeness) at some point is a waterfall. Scrum [1] often does become a collection of short waterfalls, but nothing in the kanban flow prevents a story moving in any direction. He says that epics are not enough to depict the bird's eye view on the project... But he doesn't elaborate how and I certainly disagree. And the city construction analogy is a flawed one. Cities are, in 99.9% of cases, hackjobs cobbled together over hundreds of thousands of years. There are very few cities that were planned from scratch. The "extension to the metaphor" he mentions is essentially every software project --organized process or not-- and it's the archetypal example of the software crisis. Maybe programs are not cities... I also have a very different concept of "huge requirements document" because what he described as alternative is very much a huge requirements document. The comparison to art (even if there's always an inherent artistry in software development) is because he talks about art using "shoulds". No, there are no rules for art, while there should be rules for software development (even if they ought to be flexible). [1] Actually, most of the complaints I agree with (points, too many meetings, loss of the macro view, pressure to deliver whatever at every point and in a set of defined stages) are mostly about scrum, which can be run without jira or any other tools.