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
There are some who say that Agile projects don’t need a project manager – that Agile methods are enough and ‘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 Lean 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? How long it took, so long as the end-product was great?
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”).
- 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 fulfill this role/function is a very flawed assumption. Also, sharing the responsibilities of this role in an ad-hoc way would be a very major risk in itself.
- On business, transformation and change projects, defining clear business goals, improvement objectives etc is absolutely key. This must be formally agreed well before any ‘development’ takes place. This is called, ‘the project’. This challenging task is best facilitated by one person, with the appropriate skills.
- Many projects that include software often have many non-software elements to them. In this situation, a) someone has to be managing those non-software elements carefully and b) has to coordinate the project as a whole. To assume someone in the team will just pick that up will be optimistic, at best.
- Where Design is a large-scale activity, where changes to design would have major impacts on timescale or costs, 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 in the heart of any project will make a huge positive difference.
If you agree with any of the above you may find the following pages useful:
Contact Us Now
Email us today to find out more on how we can help you.