Is Project Management overlooked during Agile transition?

I've found this question in the Agile And Lean Software Developmenet group on LinkedIn. In fact, for transparency, let me quote the entire question:

Have you ever found that project management of commissioned >projects - as opposed to product releases - is overlooked when an organisation is transitioning to Agile?

Anyone who has ever heard the sentence "There are no project managers in Agile" when working for a software supplier might have some experience of the Project Manager / SCRUM Master conundrum. Always a lively debate!

And the first (and possibly most relevant answer, not mine though):

This is a lively debate only between people who understand agile processes and people who don't. Nobody who really understands agile debates it. There's no role for traditional project management in an agile organization. Period. A Scrum master is not a PM---these are completely different roles. There is no "conundrum."

Indeed, there's really no conundrum here. There's no place for a PM in Agile Scrum and there's no need for it. During a transition from Waterfall/Prince2 to Scrum, the Project Manager is the first to go, otherwise the transition is doomed to fail.

The first pitfall is that some believe that a Project Manager automatically becomes a Scrum Master. Obviously, the most glaring fallacy is the 'automatically' part. Secondly, a Scrum Master has truly nothing in common with a Project Manager.

A Project Manager serves (a rather improper formulation, as traditional PM is the 'God' of the project on the delivery side) the project and its beneficiary.

A Scrum Master serves primarily the Scrum process itself and the team. Both of these services benefit the project, but the project is the output of the process therefore by serving the process and the team then the flow is assured, leaving the result to come naturally. The Scrum Master does not control, he/she enables. The Scrum Master is a master of the process, not of the project or the people.

On the other hand, a Product Owner might be described as a combination of a Business Analyst and a Product Manager with the caveat that the management part is nearly gone. A Product Owner doesn't manage the team (that is up to the team), he doesn't manage the process (that is up to the Scrum Master), he manages the product in terms of defining the work as well as the ellusive 'maximizing the value' aspect of said work. Rather than pushing people and reporting, the Product Owner maximizes value by managing work items and their order of delivery in other for them to have maximum value as a building block (increment). There is a lot to say here, but indeed it can be said that the Product Owner borrows from a PM and a BA.

It has been said than a Product Manager is still needed during a transition. But this is false.

Traditionally (and especially in outsourcing companies), the business model relies on charging by the hour. That means there's a wasteful system of detailed reporting required which a Project Manager needs to measure for the purpose of transparency to the customer.

This is a false transparency however, since it relies on prediction and a reporting system that is inaccurate by definition. In Scrum for outsourcing companies it is necessary that the billing unit becomes the sprint rather than the hour. The sprint is defined on the outsourcing side by its length (example: 2 weeks = 80 hours per person) and the quantity of work done (measured in points or simply in backlog items).

In this case, transparency becomes a natural outcome derived from various burn-up/burn-down charts and result of sprint reviews rather than time micromanagement.