I’ve said not to bother project managing a team of one. But what about a bigger team? What about a Scrum team?
PM free Scrum
Scrum assumes teams of 5-10 people including PO and Scrum Master. Scrum orthodoxy has Scrum as a Project Manager free zone. This works because Scrum has a very strong product development view of the world. Scrum offers a continuous stream of Sprints in which product is delivered.
Product Development Sprints – No beginning. No end
There is no project in standard Scrum because there is no beginning and no end. Scrum is purely about the the middle bit, what would be the project execution phase of the project lifecycle.
There is no project in standard Scrum so there is no PM. The two (pseudo) management roles in Scrum – the Product Owner and Scrum Master – share responsibilities with project managers but aren’t PMs.
So a pure product development team using Scrum (or something similar) won’t need a PM. It has people with some of the PM responsibilities but not PMs.
Scrum with PM
Scrum doesn’t account for all roles, nor for all situations. As Doug Stewart pointed out on a LinkedIn Group discussion:
There are no accountants in Scrum either, yet it is likely that all companies have them. We can’t presume that anything not defined by scrum fails to exist.
Just because Scrum doesn’t have a project manager doesn’t mean they aren’t needed in Agile teams. You might, for example, find that you need a PM in addition to your Scrum Master(s). For example, some folk advocate a PM across multiple Scrum teams.
Another possibility is that you do have a beginning and end. If there is a project, with a project lifecycle, then you probably need a PM and not a Scrum Master/Product Owner combination.
At the risk of being labelled a Scrumbut you could have a Scrum development team working alongside a Product Manager and Project Manager and leave out the Scrum roles of Product Owner and Scrum Master. Assuming both the Product Manager and PM where Agile aware this combination works. In fact it is the way I’m accustomed to work. As I’ve said before I don’t hire Scrum Masters – they don’t fit my context, or perhaps they don’t fit my style. And obviously Scrum Masters don’t fit the companies I work for because when I walk in the door I find PMs not Scrum Masters, despite what flavour of Agile the company purports to be using.
So whether you have a PM in your Scrum/development team depends on:
- How much you care about Scrum orthodoxy
- Whether a Scrum Master or PM fits your context
- Whether you need a PM
The final answer might be “no, I don’t need a Project Manager”, but it could also be “yes”.
This post is part of a series on Agile Roles and Responsibilities.
That PM needs to be an Agile one. Traditional PM’s in an Agile context are a recipe for pain. I think you meant an Agile PM, but please correct me if I’m wrong 🙂
Been in plenty of teams that have not had a PM. Also been in teams where a traditional PM was present but realizing that they have nothing to offer stay well away – which is good for the team but I do wonder about morale of that PM and the cost of funding a fully burdened resource that is not offering anything.
Of course been there when a traditional PM has tried to assert control and team morale goes down. Insidious blame culture is common here – e.g. ‘the team won’t do as I say’, ‘the PM is trying to control us at the expense of the project’.
Nick, I hardly ever talk about traditional PMs. So, yes, an Agile PM although I thought I’d covered that with “assuming both the Product Manager and PM where Agile aware this combination works”.
People who do not contribute do not stay on my team long. A few traditional types have disappeared that way.
I see nothing wrong with “control” as such – for example, in my view a Scrum Product Owner does a lot of controlling. So the question is how the control manifests. Constructively or not.
Yep acknowledge that I missed that statement. Control is something that is not necessarily a global action like a traditional PM or other traditional hierarchical roles try to exert, but within a certain remit. For example the team and only the team should decide how to build the product. The PO has final say on the order of the backlog.