Why developers should not be happy with a project manager

I’ve been on a fair amount of projects in the past 10 to 15 years and almost all of them were waterfall. I’ve become really, really great in being able to tell if a project will fail soon or later. Not sooner or later, but soon or later. My weakness however is that I’m not really able to tell how to really run a project. I have some ideas that I preach, but it’s very rarely that I’ve been able to practice these. Of course it’s not my job, but it’d be nice to be able to tell others from experience.

I’ve just read Scrum and XP from the trenches and thought this was a great book. One thing I noticed however was when Henrik Kniberg was saying that the product owner gets to choose priority of the stories, but the team says how many stories go into a sprint. Kniberg describes how the product owner can influence this by altering stories or priorities, but the team sets the estimated velocity and thereby selects how many stories go into a sprint.

This reminded my of Microsoft Solution Framework, where in a team with different roles, there’s always the product manager and the program manager. These roles can never be filled by the same person. Putting it simple, the first role is there to make sure the customer gets what he wants. The second role is to make sure the team isn’t stressed out, can do their job, etc. That’s why the title of this post says “a project manager”, which is the opposite of “multiple” 🙂

On every single project I’ve been on, I’ve always only had a single project manager. There are of course good project managers that really take care of the team. But because of various reasons, there’s always much more work than was originally planned and with this and various other reasons, the development team suffers by doing lots of overtime.

But with the simple rules stated above for both Scrum and MSF, the development team is (to some degree of course) protected from being burned down completely by doing so much overtime, that the people, the code and as a result the product, suffer greatly.

Very soon I’m going to start a new project at a customer and will really try to practice Scrum, sprints and daily scrums that take 15 minutes at max. Maybe I’ll blog about the experiences so people can learn from it or give me some hints on what we should do. The people involved so far are also pretty anxious to use Scrum and some XP practices for this project, so we’ll see where this ends.

Conclusion so far however is that if you have only one role that mainly keeps track of some Excel sheet but hardly protects the team for overload of stories, use cases, function points, features or whatever you may call them, perhaps you should look for another job… erm, project manager.