What are the main reasons Scrum doesn't admit managers?

Question

How can I explain the fact we aren't gonna manage the team to a customer? The customer will ask why is not-managing better than managing?

Scrum introduces self-organizing teams. Why doesn't Scrum admit project managers? Wouldn't it be better if Scrum team instead was lead by a professional person skilled in planning, risk management, change management, budget management (they would assign tasks, plan the workload, optimize the costs)?

What are the main reasons Scrum doesn't admit managers? What impediments do managers cause?

Answer 1

First, some clarification is important. Scrum does not expressly forbid any job. People in the Scrum Team can have any job titles as long as it respects the structure and rules of Scrum. Further, people can exist outside of the Scrum team that support the team as long as it does not violate the rules in Scrum. Now, I've worked in Scrum teams who are supporting with a Project Manager or who have very engaged managers while still allowing for self-organization. So, the question really becomes, is it better for the team to be self-organizing or directed?

As you point out, Scrum definitely advocates for and demands self-organization over direction.

The goal of Scrum is not to optimize cost. In fact, it uses empirical process control, which is by far the least efficient form of process control. However, it is the most highly effective form of process control for solving new problems. It was conceived in a time where a vast majority of knowledge work where projects were solving new problems were using an efficient, defined process and those processes were failing for years on end. So, first thing to understand is that the purpose of Scrum is optimized to solve problems quickly.

To that end, it suggests a small self-organizing team. Some key reasons include:

Communication channels: The number of communication channels can be found with this formula: c = n*(n-1)/2. This means around 10 people becomes a major tipping point. Loads of other research supports this and actually supports even smaller teams of around 5 - 7.

Empathy: When you are trying to solve someone's problems, you need a lot of empathy for the person you're solving the problem for. Self-organization promotes ownership and a connection to the customer. Directive management promotes compliance to a task. Therefor Scrum favors self-organization.

Process iteration: Scrum does not just iterate on the product, it iterates on how the process is done. This can just be done way faster by a self-organizing team.

Creativity: Directive management focuses on extrinsic motivation. Self-organization has a mix of extrinsic and intrinsic motivation. Research has shown that extrinsic motivators constrain thinking and inhibit creative solutioning. Again, given what scrum optimizes for, that explains its lean toward self-organization.

These are a few reasons off the top of my head. I'm sure there are many more. I have to stress though that managers, team leads, and project managers do not have to be directive. I've seen plenty of people in those jobs support self-organizing Scrum teams and violate none of the Scrum rules.

Answer 2

The customer will ask why is not-managing better than managing?

I'd say:

But we do manage it. Just differently. With Scrum.

... and then proceed to explain how the various management activities occur in Scrum.

In particular, you asked:

Wouldn't it be better if Scrum team instead was lead by a professional person skilled in planning, risk management, change management, budget management?

Who says the Product Owner can not have these skills? After all, the product owner's primary responsibility is maximizing business value, which means making trade offs between features, cost, time, and quality. If that isn't managing, I don't know what is!

The difference is that Scrum makes a distinction between strategic direction, and organizing the work. That the product owner is the sole authority on the former does not mean that he gets to dictate how the team organizes the work.

(they would assign tasks, plan the workload, optimize the costs)

No, the product owner gets to schedule user stories. Which tasks are necessary to deliver that user story is at the discretion of the development team, as is by whom these tasks are done.

The development team are the technology experts, just like the product owner is the business value expert. They know more about these tasks, just like the product owner knows more about business value. Therefore, they are better placed to organize their work than a manager could possibly be, just as a product owner is better placed to judge business value than the developer team could ever be.

Answer 3

Let's lay out some statements:

1. Scrum is founded on empirical process control theory, or empiricism.

2. Empiricism emphasizes the role of empirical evidence in the formation of ideas, rather than innate ideas or traditions.

3. Empirical evidence is information acquired by observation or experimentation. 

There are no managers in Scrum teams because people figured out that self-organization is a better way to do software development than what tradition says: having a hierarchy with managers telling everyone what to do.

In a hierarchical organization of the work, with a traditional project management setup, you have managers in charge of lots of aspects of the development, an arrangement which can easily slip into a command and control method of management. This has all sorts of disadvantages for knowledge work, with one major disadvantage being that managers (who can't do the job) tell developers (who do the job) how to do their jobs. This is not an efficient way of working. Self-organization of those that actually do the work is better.

Of course, that doesn't mean you should fire all your managers. And that doesn't mean that any team can self-organize successfully. You can fail with both approaches.

There is a role for managers in Scrum, it's just not the traditional one you are thinking about (like planning tasks, assigning work, etc). Companies still need to manage their teams, this activity doesn't go away, it's just that it's management within a different mindset.

Answer 4

Self-organising teams are not something unique to Scrum, but they do happen to work very successfully for software and technology teams. One argument for self-organising is that no single person (whether manager or not) is likely to have in-depth knowledge of all aspects of a complex environment. It's therefore best to make use of the full breadth and depth of the whole team's knowledge. Another argument is that complex problems benefit from creativity and innovation, so it's useful to harness everyone's different perspective on a problem.

Having a single person assign tasks is almost always less efficient than a self-allocating "pull-system" because pre-assignment fails as soon as anything takes longer than predicted.

Ultimately, a Scrum team's key relationship and accountability is to the Product Owner. The PO is the person who decides what gets done and when. That person is usually the customer or lead stakeholder rather than the team manager.

Self-organising is not the same as self-managing however. Scrum team members still have managers, but the idea is that those managers trust the PO to prioritise and optimise the value of the work and trust the team to deliver a useful increment each sprint.

You asked in a comment what impediments a manager would cause. The biggest issue for the customer is usually that introducing a project manager takes ownership away from the PO. To the extent that the manager takes control, the PO, and by extension the rest of the team, has less control. If the customer is paying for the team's efforts that's surely an impediment.

Answer 5

You make it sound like your customer is supposed to communicate with the whole team, with the team having no directions, budget or risk management.

That is wrong.

In Scrum, this task falls to the product owner. It is the one person that communicates with the stakeholders (customers) and can set the direction, priorities, manage risks and budgets.

Whether that person is called "product owner" or "project manager" is really not important. The important thing is to tell your customer yes, we do all these things.

If you think that the things you mentioned that a project manager normally does are not done in Scrum, you need to reread the guide. Scrum is not a complete chaos, it's just a different way to get the same things done.

Answer 6

Misunderstood or Misapplied Scrum Implementations are Never a Selling Point

How can I explain the fact we aren't gonna (sic) manage the team to a customer?

You don't. This is a self-inflicted X/Y problem based on Theory X management. Don't do that.

First of all, while Scrum Teams do not have line management roles within the Scrum Team, there's nothing stopping the organization from having line management or senior leadership outside of the team. The point is simply that management is responsible for managing people, organizational process, and project outcomes—not for managing the work internally performed by the Scrum Team.

Secondly, unless you've somehow made your organizational process (or perhaps "organizational dysfunction") a selling point to your customers, your internal development processes should generally be a no-op from a sales and marketing perspective. I've never hired an outside product-development vendor because of a deep dive into their HR processes, employee review methodology, or other irrelevancies. While agile contracting can provide benefits to both customers and vendors, ultimately people are paying for a product or service, and you only need to disclose your internal processes to the extent that they impact the contracting process or deliverables.

If you have a Scrum (or other agile) process that demonstrably works well, and have an agile contracting process to match, then there's no harm in being transparent about it if (and only if) the customer cares how the sausage is made. If your has implemented Scrum in Name Only™, Buzzword Management™, or or some other ersatz agile framework that is consistently failing to deliver results, the question shouldn't be How can we make customers buy into our process? Instead, the question should be How can we fix our broken processes?

There's clearly work for your organization to do in:

1. Integrating Scrum as a successful framework within the organization.
2. Working with senior leadership, line management, and product development teams to understand their roles and capabilities within the framework.
3. Collaborating with your sales and marketing teams to understand when, how, or if to include Scrum within your sales cycle.
4. Bringing your contracting process into alignment with your sales and development processes.

In small organizations, the Scrum Master has a role to play in educating the organization. In larger companies, an agile coach or executive consultant may be needed to ensure that the framework has full support from senior leadership on down. In the end, though, senior management owns the responsibility for integrating Scrum into the organization, and for making sure that it is properly supported across all organizational functions.

Without proper tone-at-the-top, no framework or business process (agile or not) can succeed. If senior management breaks the process, or fails to fully support it, then they own the consequences. That responsibility comes with the job title. Q.E.D.