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.

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.

Vision

Imagine two European explorers in the fifteenth century hiring crews to sail to India. Explorer A sends his crew into the woods to chop trees without any further explanations.

Explorer B, on the other hand, gathers his crew and tells them about their goal to be the first to sail to India to gain easier access to their riches (mainly spices). He instills in them a vision of something they can be proud of if they can achieve it.

Which crew do you think is more motivated? Which one will finish their ship first? Exactly, that’s my point. Teams don’t need step by step instructions of how to develop a software product. They’ve done it before (at least some team members should have). They know what it takes. What they need is a common goal to motivate them and the trust that they can do it. If the team members are not entrusted to determine their own work, they will never fully commit to the product vision, nor will they ever feel the desire to make the key decisions that they should be responsible for.

Leadership

A lot has been written about Scrum sprints replacing the traditional waterfall model, but what is less talked about is that Scrum is also about leadership versus management. According to Seth Godin, “The secret about leadership is simple: Do what you believe in. Paint a picture of the future. Go there. People will follow.” “Leaders have followers. Managers have employees.“

Of course this shines a bad light on management. We don’t even let anyone outside the development team speak at our daily Scrums because we don’t trust them not to tell us how to do our job. The team is, therefore, entrusted to deliver the Product Backlog on their own, and managers are (only) expected to assist the team to build the best product possible.

There is no doubt that each group of people needs leadership to achieve a goal. But this is just another one of the skills I mentioned above. There are undiscovered leaders within your team. They might not have the title on their business cards, but they are there. You don’t have to appoint them either, people will turn to them automatically when problems arise.

Responsibility

There is an issue that remains unresolved. I like to call it the “Spiderman Dilemma“: “With great power comes great responsibility“. What if members on your team don’t want to have this responsibility? What if they are too used to their factory life, where they have tasks assigned to them and they can go home after their eight-hour day without worrying about the product they are producing? I am afraid, I don’t have the answer. After all, I guess Scrum is not for everyone. I do believe, however, that these people are the exception. Generally team members like to have some authority over their time and effort and some input into what they do, because it gives them the chance to be proud of the product they create.

So, give your team a vision and the trust that they can achieve it, not a step by step instruction.

The above metaphor was inspired by a quote from Antoine de Saint-Exupery: “If you want to build a ship, then don’t drum up men to gather wood, give orders, and divide the work. Rather, teach them to yearn for the far and endless sea.”

Drawings by Nicole Day.