How does project management fit into Agile?
If you read my last post, you’re probably thinking I’m against all forms of project management, and want to consign project managers to the dustbin of history. That is not at all the case. I actually think there is a role for (some form of) project management in Agile, especially in large organisations. It just might not be called project management and might look and work differently to traditional PMBOK / Prince2 project management.
This article will try to figure out how project managers can work in an organisation that is doing (or trying to do) an agile transformation.
Problems with traditional project managers in Agile
There are a number of reasons that traditional project management doesn’t tend to fit well in Agile methodologies.
They try to fix scope, cost and time
Project managers traditionally try and hold fast to the iron triangle. That is, they try to make the project stick to the original agreed upon plan, which described the scope, the time (which is generally a function of scope), and the cost (which is generally a function of time). In the agile project lifecycle (on Waterfall projects too, actually), the scope often changes.
Some Waterfall projects try to limit this damage to the plan (the project manager must protect the plan at all costs!) by putting barriers around change in the form of change control processes. Agile teams (and lean project management) tend to embrace change, and start off by planning out the time and therefore the cost, and letting the scope figure itself out as you go.
They’re not interested in the product
Project managers have one duty that overrides all others: stick to the plan. Make sure the project delivers all of the agreed scope, on time, and on budget. It doesn’t matter if the scope is stupid and nobody wants it, it doesn’t matter if the benefits will never make up for the cost. It must all get done according to the original plan.
Agile planning tends to be more interested in the product than the plan. Keep trying to build a great product, and plan as you go. It recognises that any original plans were based on very little information and therefore should be regularly revised.
They’re not interested in the team
Project managers generally move from project to project and from team to team. They generally have no interest in the health and happiness of the team or their long-term viability. They are often therefore happy sending teams into a “death march” (late nights, regularly working weekends) to get the product shipped with all agreed scope, on time, and on budget, at which point they can go and attach themselves to another team and send them through the same routine. Agile tends to not have project managers and instead have scrum master roles and product owners, that look after the long-term health of the product and the team (well, they are supposed to).
What the scrum master, the product owner and the development team do
If you read most of the agile blogs and books, they’ll tell you that you don’t need or want a project manager, partly because of the reasons above, but also because (if you’re doing Scrum project management or something like it, which you probably are), you have a scrum master, a product owner role and a scrum team instead. And these people should be able to do all the things a project manager needs to do, plus other things that project managers don’t do.
The scrum-master looks after the team and the iteration
The role of the scrum-master is complex, but fundamentally their job is to look after the team (make sure they are able and happy to do work, make sure they have the tools to do their job, make sure they aren’t being put on a death march), and to protect the iteration (make sure people aren’t sneaking in other work that wasn’t agreed to). They are also supposed to do some reporting by looking at things like burndown / burnup charts, which tell you how you are progressing to release goals, but the official Scrum canon doesn’t say much about this.
The product owner looks after the product
The job of the product owner is to look after the product, i.e. make sure it makes sense, it will achieve benefits, and it is aligned to the business goals and strategy. This is the domain of what traditional project managers would call “stakeholders”; the difference here is that this key stakeholder (they are generally a proxy for a larger group of more powerful stakeholders) is actually part of the scrum, so is right in the middle of the action.
The development team build things and make all the decisions about how, when and by whom things get built
The development team are responsible for pulling work from the product backlog into the sprint backlog, which means they effectively control what scope gets built and what doesn’t (e.g. if they decide a story isn’t yet ready to be pulled in, they can leave it where it is and not pull it into the sprint and that’s that).
They are empowered to self-manage in regards to who does what work. In agile project management principles (or Kanban project management), there are no Gantt charts specifying who should do which tasks, as per traditional project management. And they can re-arrange the order of work in the sprint backlog as they see fit (they’re not allowed to do that to the product backlog, that’s the domain of the product owner).
What the scrum master and product owner probably don’t do
So these guys have it all covered and we don’t need anyone else, right? Not necessarily.
You might need someone to interface with external groups
In a sufficiently large organisation, a scrum team is not going to operate in a vacuum. There will need to be interactions with other groups like risk, security, privacy, finance, integration, marketing, change management, and possibly a dozen others. You need someone to manage all of these: find out who to engage with, go through the necessary administration to engage them, follow up on actions or deliverables. I doubt anyone in the scrum team has the capacity to do that.
You probably need someone to do release management
In a sufficiently large organisation, there are probably still going to be some kind of big releases, even if you are working on (and releasing something in) iterations. You probably need someone to plan and track these releases. What features and stories will be ready, which defects will and won’t be fixed. What other teams are releasing and what those impacts will have on you. This, combined with the release tracking and reporting mentioned earlier, probably needs to also be done by someone outside the scrum team.
Any sufficiently large organisation will probably need someone that looks a bit like a project manager
So these two tasks are the key roles I see a project manager doing in agile if done at a large bureaucratic organisation. You don’t need to call them a project manager, you can call them whatever you like. Agile project manager maybe. But these things need to be done. They are probably not a full-time job so like a scrum-master with an experienced team, the person could probably sit across two or three teams.
Do you think you are able to succeed with agile leadership if you don’t follow and apply these principles? Let me know what you think in the comments.
