In 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.