If you just read the subtitles, I'd almost think your article was a piece in favor of Kanban. Engineers aren't assembly workers: so why do other methodologies

If you just read the subtitles, I'd almost think your article was a piece in favor of Kanban. Engineers aren't assembly workers: so why do other methodologies seem to be so prescriptive on what can be accomplished in a given time frame? New problems arise, priorities shift, and unexpected news arrives. I appreciate the flexibility of a pull-type system because it lets me transparently show what I'm working on. I've really hated telling people no or watching a manager struggle to change up something we really need just because it doesn't fit in the right shape time box or might affect the current sprint's plans. You can't trust yourself: I always ended up hating sprint planning meetings where "points" are a constant source of conflict between stakeholders and estimates are fantastical. These sort of meetings just allow the quality knob to turn down while scope and schedule remain fixed. Having an entire team minimizes estimates problems, but for the effort involved I'm not sure the gains are worth it. Also, I think you may have inadvertently taken Anderson's quote out of context as well—Kanban isn't a way to run software. It's merely a way to expose your current process so you can improve it. Kanban is something that sits on top and allows you to identify bottlenecks, be realistic about results (instead of estimates) and provide immediate transparency into what you're working on. It doesn't specifically prescribe what the steps are.