Quality Software Development with Ease

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 costumer 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 costumer some wiggle room. You know your costumer’s requirements will change. So, why tie them all down before even starting the project? This usually requires you to educate your costumers 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 costumer 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.

Yesterday I registered for a website, and the drop down list for job titles had entries for ‘Project Manager/Scrum Master’ and ‘Developer/Engineer’. I was in a bit of a dilemma there. I am currently Scrum Master AND developer on my team. I never really considered Scrum Master being a job title, so I picked developer. Problem solved, right? But wait, ‘Project Manager/Scrum Master’?! Are they the same? Same category at least? Is a Scrum Master a lightweight Project Manager? – I think: No, possibly and sort of.

Project Manager (PM)

The PMI Project Management Body of Knowledge recognizes five basic process groups and nine knowledge areas being typical of almost all projects. These are the domains of a Project Manager. The five basic process groups identified are

1. Initiating,
2. Planning,
3. Executing,
4. Monitoring and Controlling and
5. Closing.

Some or all of these processes are contained in each of the nine knowledge areas consisting of

1. Integration,
2. Scope,
3. Time,
4. Cost,
5. Quality,
6. Human Resource,
7. Communications,
8. Risk and
9. Procurement.

Scrum Master (SM)

The Scrum Guide defines the Scrum Master role as follows:

“The ScrumMaster is responsible for ensuring that the Scrum Team adheres to Scrum values, practices, and rules. The ScrumMaster helps the Scrum Team and the organization adopt Scrum. The ScrumMaster teaches the Scrum Team by coaching and by leading it to be more productive and produce higher quality products. The ScrumMaster helps the Scrum Team understand and use self-management and cross-functionality. However, the ScrumMaster does not manage the Scrum Team; the Scrum Team is self-organizing.” [emphasis is mine]

Comparison

Both SMs and PMs try to create an environment that enables the team to do their work. They are facilitators. However, they are doing this in completely different ways. SMs manage the development process and remove obstacles identified by the team, whereas traditional PMs manage resources (including the team members) and do all of the planning, monitoring and controlling involved.

For Scrum teams, the project planning consists of

• the Product Backlog,
• the Release Backlog (both owned by the Product Owner) and
• the Sprint Backlog (picked and estimated during the Sprint Planning Meeting by the development team)  together with
• the corresponding Release and Sprint Burndown Charts (kept up do date by the SM).

The SM monitors the team’s achievements during the sprint using the Sprint Burndown Chart and raises discrepancies to the Product Owner, who then controls the outcome of the sprint by adjusting its scope. The development team also monitors and controls its own progress daily during the Daily Scrums. In Scrum terms this is known as inspect and adapt. This means the PM tasks of planning, monitoring and controlling, are shared by the SM, the Product Owner and the development team.

A traditional PM would do all these tasks by himself after gathering the status from the team in regular meetings. This also means that he is held ultimately accountable for the success or failure of the entire project.

Conclusion

And so, I would answer the question, if Scrum Masters are the new Project Managers with a definite ‘No’. Scrum Masters fulfill some of the tasks of a traditional Project Manager, but so do the other members of a Scrum team, i.e. the Product Owner and the development team. Should PMs become SMs then? Possibly. However, it requires a lot of discipline of the PM not to try to manage the team, and not to tell them which tasks to tackle next during the Daily Scrums. Since it is the SM’s responsibility to enforce the Scrum process there is no-one to correct the PM in case he falls back into the old rut. It is more common that SMs are recruited from within (while possibly still being part of) the development team.

Consequently, is there no place for Project Managers in Scrum? I shall cover this question in my next entry.