Delivery Management vs Project Management

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.

PMO Role in Agile

If you lead a PMO or are a PM and your organization is embarking on an Agile adoption you are probably thinking so how do I fit into this new paradigm and still manage the work that I'm currently managing (it won't manage itself is what you are thinking) ?

Organizations who are now moving towards Agile as a product delivery/SDLC method will find themselves trying to figure out where their PMO and subsequent Project Managers will fit.

The problems they face are several:

Traditional Project Managers:

• Are experienced at managing to a specific plan and resolving resource issues that their specific projects are facing.  They are not typically assigned to just one project and the people they work with come and go with much frequency.  Project Managers have been for many years the ones who provide confidence that 'someone' has their hands on the pulse of the projects that are designed to deliver value to the organization.
• Don't typically look at their projects as value driven, rather they are priority and resource driven.  Their focus when they are assigned to a project is about who is on my team, who can I steal from other projects and creating a plan that is often not vetted by the very people who will actually do the work and socializing that with Sr Management.
• Traditional Project Managers are excellent deflectors of blame (yep I learned quickly how to push off issues on to someone else)
• Are not typically contributing members of the team.

I don't say these things to make Project Managers angry, I was once a PM and a very good one at that (or so I believe).  And I'm not at all implying that there isn't a role for PM's in Agile, but I will suggest that how you think as a PM will need to change.

For starters you need to find a way to be a contributing member of the team and not just someone who sits on the sidelines like a reporter and records what is going on to report out.

The thing that was different about me was that I always managed my teams more like a Scrum Master would.  I found ways to contribute, I gained the trust of my team, I protected them and provided guidance for individuals when they were struggling with something about the organization that didn't make sense.  This process of engagement led me out of the PM role and ultimately into QA Management so there are growth opportunities for PM's if you are open to learning new things.

If the team needs help in testing, learn something new and help out.

Most Agilists' may tell you that the Scrum Master and Project Manager role are completely different.  Though they are different I would argue that project managers can fill the void of Scrum Master and gain great insight to their projects and be on point to resolve impediments more easily than be bystanders to the entire Agile process.

Here are some key areas that Project Managers should focus on during an Agile Transformation:

1. Planning - Is not a function of setting forth an unyielding plan.  Rather planning by the team is to facilitate an ever growing understanding of what the team is building.  Big Up Front Requirements convey a static nature to projects that simply doesn't exist.  If you disagree actually track the number of times the team has to change their plans (for architecture, etc..) during a typical non-Agile project.  Teams that try to predict the future are destined to be wrong a majority of the time.  You need to become comfortable with a plan that identifies in detail only 4 weeks out.
   1. Goal - Be an active member of the team and be able to understand both the technical issues that are facing the team and bring them a clear understanding of dependencies with projects and teams that aren't in their viewfinder.
   2. Goal - Learn different Agile planning techniques.  One of the key things that people miss in Agile adoption is that Planning needs to take place more often and that some level of upfront Discovery is not a bad thing.
2. Scrum/Agile  Activities - A Project Manager for a Scrum Team needs to:
   1. Ensure that their teams are performing effective User Story development with techniques such as BDD and Specification by Example.
   2. Ensure that their teams have a well groomed set of stories in their backlog
   3. Ensure that their teams have effective Sprint Planning and Estimation sessions
   4. Ensure that the teams utilize their Retrospectives to drive continuous improvement
      1. Goal - Become an Agile evangilist, learn everything you can about Scrum, Story writing, TDD, Continuous Integration, User Story Mappiing, BDD, Specification by Example.
3. Program Management - Is driven by the overall roadmap.  Ensuring that Scrum teams are aligning their user stories to appropriate Road Map Items keeps the organization focused on execution progress/success and provides the PMO with a clear view to all of the work that they are managing.  As an organization scales this is no small feat, so getting large sets of teams to keep up with story writing and roadmap linking is an administrative task that teams quickly tire of.  Project Managers need to provide support and assistance with the management of these types of activities in conjunction with their PO and Scrum Master.
4. Technical Knowledge - Though this isn't as big of a problem as it was 10 years ago, many Project Managers simply don't understand the underlying technical platform that their teams are working in.  I personally don't think that you can be an effective project manager unless you have this knowledge.  Take the time to learn, your team will appreciate it and you will be able to have better fact based conversations with your Stakeholders regarding issues that delay delivery of projects.