In Agile we have evolved from a 'project' oriented mindset to a product one. That is not to say that we don't undertake a something that looks like a project to build or enhance our products.  However in Product Management we are more focused on the ongoing nature of how our product will unfold, in shorter durations and without the end in site.

I believe successful Agile Project Managers need to focus on Delivery Management over Project Management.

What is the difference?

1. Delivery Management - Is the management of work in an iterative fashion that focuses on delivering product that delights our customers.  It is not focused on Time, Scope and Budget, but rather on customer experience, high quality code and low defects. Delivery management focused on long-term value and benefits over planned short-term objectives.
2. Project Management - is the application of processes, methods, knowledge, skills and experience to achieve the project objectives. A project is a unique, transient endeavour, undertaken to achieve planned objectives, which could be defined in terms of outputs, outcomes or benefits.

Having been a project manager in a waterfall/PMI world before my move to Agile some of the mental challenges I faced included:

1. Lack of a plan - One of the first things I did as I was moving to Agile was to track the amount of 'change' that happened in one of my waterfall projects.  I created a Project Change Request for everything that was not originally identified in the Business Requirements and Technical Design Documents, assumptions that changed, scope, etc... This process drove my team absolutely crazy because as with all waterfall teams, we fear change requests, they are bad news to management.  However what this effort did was provide visibility to the type of change that happens in every single software development project (and these changes were never socialized outside of the team so they had nothing to worry about).
   1. Realization - 
      1. My project plans provided no real ability to know if a project was going to be successful, they looked good but didn't tell the real story of what was happening with the project team and what they were developing.
      2. Agile provided me with much more visibility to the real issues that a project team faced and that my project plan was really just a place holder for future Sprints.  I only needed to know that the Sprints were planned and then communicate what the team was committing to.  Once I had that information THEN I could hold them accountable.
2. Story Points over Time bases estimates - I had a really hard time initially wrapping my head around Story points over time and spent many an hour mentally putting the points back into hours.
   1. Realization -
      1. I finally stopped thinking in time once my team started 'delivering' consistent points and work for every sprint.  At that point all I ended up needing to know was the story points of work begin committed to.  The point here is as a Project Manager you need to instill good estimation behaviors with your team and hold them accountable, that IS your job.
      2. Velocity is the primary data point you want to focus on, consistent velocity = consistent delivery.  It's not your job to determine the What for the product but it is your job to ensure that what they commit to does get Delivered (though if you work to be a valued member of the team, you should definitely be able to provide input).
3. Status Reporting - Ah the bane of our existence as project managers and something that I had to deal with recently, the dreaded status report.  Honestly I hadn't been a project manager for many years and as a Manager I never needed one with Agile teams.  All I needed was a dashboard (Jira or Rally are the ones I'm most experienced with) to observe a teams backlog, Velocity and Progress towards a Roadmap they were working on.
   1. Realization - The status report will not every go away but I think you need to ensure that your reporting is consistent with the rest of your Agile processes.  Tools such as Jira and Rally provide you with abilities to manage Roadmaps, teams, budgets, etc... Everything is still there but your reporting needs to take advantage of the data elements within Agile, don't translate your Agile into a waterfall type status report.  This will only ensure that Sr. Management stays disconnected from Agile and the entire organization needs to be plugged into Agile and walk the walk.

If you are a traditional PMI type project manager and are moving to Agile here are some things you should consider:

1. You are not responsible for the success of a project/ delivery - Yeah I know it sounds wrong, but in Agile it is the TEAM that is responsible for delivery.  You need to plug into your team, get to know what they do, the challenges that they face, become a sounding board for ideas, get your hands dirty, learn how to test, etc...Becoming a valued member of the team is what moved me out of Project Management and into Quality Assurance. 9
2. Be an Agile advocate - Embrace agile so that you do more than go through the motions. Read, learn, join a meet up group, do more than just the minimum.  As a Project Manager you can help your organization get better at Being Agile, you have the connections and understanding of the organization that many in the technical side may not.
3. Don't be Defensive- As you will learn, Retrospectives should be frank and open conversations about what is working and more importantly not working in your processes.  Encourage your team to openly talk about issues, but protect them so that they can continue to work effectively as a team, remember attack the problem not the person.  For example at Disney where I both QA Manager and individual contributor my duties as QA Manager were getting in the way of my ability to test and give good feedback to the team.  They rightly called me out in a retrospective as being the issue for them not moving as fast as they could.  I was not defensive but understanding, that is what you want in Agile, because they were absolutely correct, I was the problem at that point.

So as you look at what you manage in traditional project management, understand that it is not the Project that you are delivering but a Product and Products have much longer life spans than projects.

You need to keep your teams focused in consistent and disciplined delivery that brings real value to your organization. If you are working on something that doesn't have value you should be questioning and challenging your team as to why.

Agile isn't easy, though I think it is often thought of as easy.  No Agile is very disciplined and when you undertake Agile it will highlight every inefficiency and poor process that exists in your organization today.  You simply cannot go fast until you address these issues.  As a Project Manager you can help drive this change.