> Imagine throwing out every process you just described (minimal specs and plans, no contracts, no documentation, avoiding as many processes and tools as possib

> Imagine throwing out every process you just described (minimal specs and plans, no contracts, no documentation, avoiding as many processes and tools as possible), and instead replacing them with conversations. You'd have those conversations (dev to dev, dev to PM, PM to customer, dev to customer), spend a few days building software, and then have those conversations all over again, continuously looping until the product is either "done" or something more important came up to work on. > Would you call that team "agile" or "waterfall"? Waterfall, 100%. I've been through that hell - management comes down with a date and brief elevator pitch. Then we're in constant talks over the next two weeks to hit a date no one really understands the requirements or rationales of, ironing out responsibilities between teams without any holistic long-term architectural vision (because there isn't even a product vision). > I'm not sure I know how to square "Working software over comprehensive documentation" with "well defined stories with great documentation" and "clean specs upfront". Comprehensive documentation literally means a very high coverage, perhaps 100% coverage of architecture docs, tutorials, design specs, etc. I said "well defined" and "great" :) Agile is not contrary to documentation. Instead, there is a recognition that documentation's value is the time saved on development/discussion. That balance point depends on the team, and should always be considered in retrospectives. If you're a team of 3 that all know how everything works, without immediate growth prospects... yeah, who needs docs? On the other hand, a FAANG team of 12 growing to 30 over the next 3 months will need documentation. My "right-level" of documentation is that a junior engineer can pick up a story and ship it alone. The story is not fully-defined - implementer will have to learn some things from the docs, read through some of the code, decide on implementation strategy themselves... but they should be able to do so without meeting with others. Meetings are expensive for teams, and context switching is expensive for ICs. Meetings that require bringing in senior engineers[1] for story-level details is all but an organizational anti-pattern. [1] Generally, I'd regard having any single SME in the critical path of implementation is an antipattern (borrowing from kanban, this person invariably becomes a bottleneck on a large fast-paced team)