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.
There are a number of reasons that traditional project management doesn’t tend to fit well in Agile:
Project managers traditionally try and hold fast to the iron triangle, i.e. 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). On Agile projects (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 projects 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.
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 costs, it must all get done according to the original plan. Agile 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.
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 masters and product owners, that look after the long-term health of the product and the team (well, they are supposed to).
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, which you probably are), you have a scrum master, a product owner 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 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 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 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 (no Gantt charts specifying who should do which tasks, as per traditional project management), and 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).
So these guys have it all covered and we don’t need anyone else, right? Not necessarily.
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 possible 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.
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.
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, 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.