I'm not sure if your comment will get much attention because of how strongly worded some of it is, but I feel it contains a nice insight about the relation (and potential tension) between Product and Process.
If your hypothesis holds, then perhaps that this is why Scrum appears well-suited to people doing client work!
The client has the responsibility for product/market fit, and "the realities of the business." The software shop they may hire to build something will doubtless think deeply about finding and exposing the value in their concept to users, but at the end of the day the contractor is already insulated from the next-level, "should we be building this or something different?" questions.
One of the best projects I've ever worked on was making an effort to be agile -- but not to adopt any packaged process! 2 fulltime devs, 2 part-time, weekly sprints with working code, story/task level breakdown of effort with estimation/hours assigned to stories, 5-10 minute stand-ups, retrospectives only over email if there's anything we want to talk over ... the people who were on that project still feel like it "just worked" and that it was one of the more pleasant and 'agile' projects they've ever been involved with.
... but, as so many other messages here mention, the reality is that the product itself was the key. There was a good, simple product vision, which the product's (deeply technical, programmer) owner and the lead developer (myself) shared. And, again potentially supporting your hypothesis, it was client work (a tool that salespeople used to do quick mockups for leads on their iPads; it's not a consumer product but it was at least heavily used, and replaced an inefficient manual process).
If your hypothesis holds, then perhaps that this is why Scrum appears well-suited to people doing client work!
The client has the responsibility for product/market fit, and "the realities of the business." The software shop they may hire to build something will doubtless think deeply about finding and exposing the value in their concept to users, but at the end of the day the contractor is already insulated from the next-level, "should we be building this or something different?" questions.
One of the best projects I've ever worked on was making an effort to be agile -- but not to adopt any packaged process! 2 fulltime devs, 2 part-time, weekly sprints with working code, story/task level breakdown of effort with estimation/hours assigned to stories, 5-10 minute stand-ups, retrospectives only over email if there's anything we want to talk over ... the people who were on that project still feel like it "just worked" and that it was one of the more pleasant and 'agile' projects they've ever been involved with.
... but, as so many other messages here mention, the reality is that the product itself was the key. There was a good, simple product vision, which the product's (deeply technical, programmer) owner and the lead developer (myself) shared. And, again potentially supporting your hypothesis, it was client work (a tool that salespeople used to do quick mockups for leads on their iPads; it's not a consumer product but it was at least heavily used, and replaced an inefficient manual process).