“A properly engaged customer is essential to agile running well.”
I agree and I see it as essential to other methodologies as well, such as Waterfall. Without a customer who’s pulling their weight, the rest of the project will be directionless and will soon fall behind.
In some Agile projects, customers will attend the stand-ups and provide direction. But on my current project, for example, we are building a green field app and are five months away from launch. The customer rarely attends the stand-ups. Instead, they interact with the BAs in separate meetings. The BAs turn these discussions into detailed user stories that we are free to implement whenever we believe appropriate. As long as they’re coded and tested by our predetermined launch date, we’re fine.
Overall, my point is that everyone has to engage in the process. If a customer disengages from any methodology, then some problem will develop. I believe that problem is the fault of the customer, not the fault of the process that the customer is ignoring.
In Waterfall, a disengaged customer results in late requirements and specifications. This happens before development gets significantly underway, so if change control is in effect (as it should be) this damage can be controlled by extending the delivery date. If the PM skips change control, then that’s a second person who is choosing to not follow the process.
In Agile, customers are engaged in different ways. Some are engaged in the stand-ups and some aren’t. My project is an example of the latter. I see the customer once every few weeks. I hear about their decisions via the BAs. But if they become unavailable, then the project will certainly suffer. I wouldn’t blame Agile for that any more than I blame Waterfall for similar choices.