Why many Agile projects still need project managers:
The good things in Agile:
Firstly let me say, I am a huge fan of the good that Agile can bring, through some of the practices that it encourages (e.g. collaboration, transparency etc). Like all “new” ideas though, there are some whose interpretation goes beyond the bounds of what is good. There are also some very experienced people in the Agile world, who believe that Agile projects also need project management.
This post is not about traditional-v-Agile ‘methods’
Secondly, this post is not suggesting we apply many of the ‘traditional’ forms of PM to Agile projects, as that would be like mixing oil and water. We have never advocated or believed in “command and control” styles of project management since we were founded. However.
The purist’s view
Some say that Agile projects don’t need a project manager – that Agile methods are enough and that ‘the team’ will just do what needs to be done. Personally, I will go on record and question their motivation for saying this and let me share with you a simple comparison. Imagine those same people were doing their own large-scale (expensive) home improvement project and someone said: “we’re going to use Agile on this project, you don’t need all that project management stuff”. That could lead to a situation where no one was looking after: budgets, timescales, dependencies, risk, stakeholders (outside of the very core team) and more. But that would be OK surely? Those same people wouldn’t mind how much the project cost. Or the fact that a great chunk of the original scope did not get done?
In the real world:
In business, many projects are no different to the home-improvement project (at least in some ways). There are real reasons why on an Agile project, it is not just useful to have an effective PM, it is absolutely necessary. It also goes without saying, that the PM should understand Agile and its implications for the whole development process. However, there will be times when the PM will need to have input into the routine planning decisions (e.g. Sprint planning) within the development process.
So here are some key reasons why many Agile projects do need a project manager and I am not alone in this view:
- Agile (methods) relate to product development, not project management (for example, projects don’t “begin with a product backlog”). On vast numbers of projects, countless other things have to be managed and many will result in dependencies between themselves and the product development effort. Methods like Scrum ignore these completely, as in this real-world example that was shared with me in May 2018 (1).
- Given many projects that include software often have many non-software elements to them, to assume someone in the team will just pick that up will be very optimistic, at best. In this situation, a) someone has to be managing those non-software elements carefully and b) needs to have a view of the project as a whole.
- Most Agile methods don’t deal with many of the important project management disciplines that are key to many projects being successful. Assuming anyone (in the team) can fulfil this role/function is a very flawed assumption. Also, sharing the responsibilities of this role in an ad-hoc way would be a disaster.
- On business and change projects, having clear business goals, improvement objectives etc is absolutely key. This must be formally agreed upon well before any solution ‘development’ starts. This is called, ‘the project’. This challenging task is best facilitated by one person, with the appropriate skills.
- Where Design is a large-scale activity, where changes to the design would have major impacts on timescale or costs, the use of Agile is not impossible but would have to be applied with a huge level of skill and experience. It would not be possible to “leave it to the PO (alone)” in those circumstances to have the time or the understanding of the project to make certain calls, for example when trade-offs are necessary. Many Agile methods say little if anything about Design. They focus on the development of the functionality of a system.
- On larger Agile projects, where software development breaks down into many teams, there will be a need for coordination across and at a level above the teams. Skilled project managers are ideal people to do this.
- Where Scrum Masters exist, they are facilitators of the Scrum process. They can overlap with some of the PM role, but they will very rarely (if ever) carry out all of it.
- The PO is certainly not a PM. They are there to provide input to the project and development teams. For example. There will be times when you need to make trade-offs between requirements and timescale etc. In a well-run Agile project, the call on those decisions should belong to the PO and many people will have an input. It is unlikely that a PO would have the time to do a proper analysis in these circumstances and the PM could play a key role in facilitating this. This example will often fall well outside the remit (and even skills) of a Scrum Master.
- Self-organised teams are great in theory – in practice, few teams genuinely self-organise without (at least) some form of facilitation. In addition, self-organisation is not management. If you have targets or constraints relating to your project (project, not the product), someone needs to manage these elements.
- Businesses still need to know about and manage: budgets, resources, risk, timescales and other things that PMs are typically responsible for doing.
Most important of all is that project management is a skillset, not a methodology. Having real PM skills available and present at the heart of any project will make a huge positive difference.
- The following was shared with me relating to a major IT project in a US Government department in May 2018: “Yep, we had lots of challenges implementing Agile for important parts of the project that didn’t involve software development – training, contract management, RFPs, HR, data migration, coordination with external integration partners, etc. Scrum seemed to pretend those things didn’t exist and no one needed to manage them.”
If you agree with any of the above you may find the following pages useful: