Are Project Managers not needed with Scrum?

No_admittance_signIn my last two entries I wrote about managers being excluded from Scrum and why Scrum Masters are no Project Managers. Does this mean that management is not needed? Are all management positions obsolete in software development with Scrum? Certainly not. The reason why managers often get bashed when talking about software development with Scrum, is because of the scope of Scrum. Scrum focuses on project execution, from project inception to project completion. This is on a level that an empowered team can handle. No managers needed.

Beyond Scrum and project execution

Before you start screaming, bear with me for a moment and read on. We all know a project doesn’t just start when someone has a brilliant idea for a product and writes down some requirements in a Product Backlog. There is more to it, much more I am afraid. Things like Visioning, Project Approval and Staffing. Also, the engagement with your customer might not end with the deployment of the product into their environment. You are likely to also provide training and support for the product that you delivered. This is where Lean Principles come into play and can provide valuable guidelines beyond Scrum. One of the principles in Lean Thinking is to “optimize across organizations“. Lean considers products from concept to cash. It focuses on the entire organization. This is where management plays a key role. To achieve this, managers have to coordinate teams as part of the whole, but they don’t have to tell the team members what to do from start to completion of the development effort. Empowered (Scrum) teams will handle this just fine.

So, the reason why managers are not mentioned in Scrum, is because Scrum operates on a level below where management is needed. Managers don’t have to get wound up with trying to micro-manage teams. Instead they can concentrate on creating an organizational structure for teams to work in.

Appropriate project plans

For the very same reason, there is no place for a traditional project plan in Scrum. Think about it. Who is asking you for a project plan? Is it your development teams or is it your customers? That’s what I thought. Your customers want to have a project plan so they know when the product will be finished and how much it is going to cost them. The reality (in most cases) is dead simple: No project plan, no project. Here comes the BUT. This project plan needs to be based on estimates from the team and on a high enough level to give them and your customer some wiggle room. You know your customer’s requirements will change. So, why tie them all down before even starting the project? This usually requires you to educate your customers to be comfortable with a certain level of uncertainty. Unfortunately, many customers would still rather have a detailed project plan with the certainty that it will be wrong.

Trust is the foundation, again

Comfort with uncertainty  is based on trust. The trust of your customer in your organization. I mentioned trust before. The trust your empowered teams need to self-organize and to achieve the given product visions. This trust ultimately needs to come from your customers. Trust that your organization will act in their best interest and also in your capability to do so.

Project Managers have to advance too

All of this presents challenges to both Project Managers and the organizations they work for. It requires a change in the way they used to work, a change in mindset. The business is accustomed to completely defining cost, time and scope at the beginning of a project. To deal with uncertainty and risk, Project Managers have to acquire new skills in techniques such as rolling-wave planning or progressive elaboration.

So, yes, I do think there is a place for Project Managers in agile organizations, but like the rest of us, they need to keep learning new skills to keep up with the industry standards of developing software.

Reblog this post [with Zemanta]


  1. Great post Manuel. There is a place for project managers in an Agile team, however the “manager” part of the title is what changes. So rather than telling people what to do and when to do it, as you say, their job becomes creating environments for the team to work in. This includes removing impediments to keep the team productive, rather than watching hours and needling developers about their progress. The role is there, it’s now different, requiring different skills.

  2. Hello, I would like to add something to the discussion about Project Management. Actually I want to give an example about how different it can be to what you are suggesting with scrum.
    OK, I am not working in a Software development project, but in a project to build up a complete IT-environment including developing services for that environment. But I think this should not make a big difference.
    Due to resource problems I am the only one working on all issues. There are lots of open issues which have to be prioritized, estimated etc. As usual.
    But since management wants exact forecasts about how many working days we will still need, about when we will finish what etc., I have a Project Manager which is busy working with the Project-Management-Tool (JIRA) and Excel full time. Additionally one manager has an eye on the status of these project-sheets. Additionally we have to meet every three weeks with a management team to discuss the status. Additionally one Controller has an eye on the progress.
    So I think my project is about 30% development and 70% project management.
    What do we learn from this: There is a price for having exact numbers as a manager. Of course they would like to know exactly what utilization they will have in the next three months. But the cost for this information is very high.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s