The word "customer" is problematic. Many people mentally associate that term with the person who paid for the system, not those who will use it. This is a perennial problem with all approaches, agile or not. There is a tendency for product owners and business owners to think they remember exactly what the problems are for a job they themselves may have held 5 - 15 years ago. They truth is they may no longer have a clue.
I've heard it over and over again in situations ranging from business applications development to high tech, "I know what my people need!" This is not exactly like Bill Murray's character in "Scrooged," but it still is arrogance, however benignly intended and kindly stated. It is like a general who was an F4 pilot grousing that he knew what pilots needed in an F-22; he didn't. He was very knowledgeable about flying, of course, but did not have the gut feel of flying modern, high-performance aircraft. This type of situation is a headache stretching 'way back, and part of the steps we took in over-specifying requirements were due to trying to punch through to design so we could get our hands on real, live end users that we were denied contact with during elicitation. The result was design-heavy and superfluous requirements, which created an administrative headache once we had to eternally maintain and modify them based on reality checks. We knew it was stupid, but we had to work the system the best we good.
This was not automatically fixed by Scrum.
The end-user involvement problem persists today, in die-hard, 100% Scrum shops - there are lots of people who know exactly what the system should do, but the developers are insulated from those who know best how it should do it. Demos, incremental rollouts, etc., make no difference if the end users are not invited and have no real voice until the cumulative "done-done" rollouts create enough performance problems that they howl too loudly to be ignored.
In these situations the Product Owner/Business Owner model represents a bottleneck. Why insulate the developers from the end users via a lossy, "telephone game" communication path such as a Product Owner? I suspect it is to address the same problems we had pre-Scrum when every end user and business owner could originate a new requirement without accountability, or no one could originate anything new without a strangling, heavy committee. But the attempt to control the "pet programmer" phenomenon, over-specification, and other problems with traditional requirements engineering has reproduced one of its key problems: a communications choke point.
This post may attract anecdotes to show it's wrong. But many of those anecdotes will come from situations in which the impact of a component or feature is very quickly evident to the developers themselves, such as in web front-end applications. In systems-of-systems and highly complex business applications, the ultimate impact is difficult or impossible for a development team to anticipate without end-user involvement.
This is not a criticism of Scrum per se, just pointing out that it does not explicitly address the age-old problem of getting access to the real environment and users of a system. Scrum does help us reduce chaos by a disciplined use of Product Owners. But Scrum, like any method*, can reach that point where the organization must evolve beyond the method's most common, literal interpretations. Methods can provide a framework to support (or hinder) development of knowledge, experience, wisdom, humility, and common sense, but no method can replace these things. We should use methods while they are useful, and move on when we are ready.
=============================================================
*Some will object that Scrum is a framework, not a method. It started out looking and sounding a lot like a methodology, and was later redefined as a framework by its authors.
Shawn Presson - SP4, CSM, PMP, CMMI-DEV