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?

  • 2
    Could you ask a more specific question? How I read this is "Scrum says to self-organize, isn't not self-organizing better?" That would be mostly a value judgement and we could probably write books about it. (more to the point, people have written books about it)
    – Daniel
    Commented Oct 23, 2020 at 14:44
  • I made the question a little more specific.
    – Daniel
    Commented Oct 23, 2020 at 14:47
  • It might be worth noting that there are Agile methodologies like DSDM that do include managers.
    – nick012000
    Commented Oct 24, 2020 at 5:57
  • Who says there can't be managers in scrum? We use Scrum with managers all the time.
    – Helena
    Commented Oct 24, 2020 at 21:29
  • 1
    You might want to read The Manager and Scrum, which goes into a lot of detail on, at least, one way to think about the role of managers in self-organizing teams. Commented Oct 24, 2020 at 22:34

6 Answers 6


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.

  • How can you sell Scrum to a customer/buyer if you say that it's not the goal of Scrum to optimize the customer's expences? No customer will buy it.
    – Daniel
    Commented Oct 23, 2020 at 15:52
  • This is a sales/customer relationship question. It's about framing. Let's start with a stark choice: would you like to cheaply get a solution that half-solves your problem or pay half again for a solution that fully solves your problem? A talented sales-person can ask that question in a better way. This is certainly not a Scrum problem. Millions of sales people have to position quality over price all the time.
    – Daniel
    Commented Oct 23, 2020 at 16:33
  • I think other Scrum professionals will argue that they will make up the cost by eliminating rework and inefficient processes, but I don't like to. I think it's worth having the conversation with a customer of if they prioritize efficiency or effectiveness over the other. I find this a more valuable conversation, but take your pick.
    – Daniel
    Commented Oct 23, 2020 at 16:37
  • 6
    @Daniel to me it seems weird that you need to sell the way the team works to the customer at all. They should care about getting their stuff done and the "how" should be the problem of the contractor. Is this perhaps an X/Y problem? I.e. most contractor companies I know wouldn't even divulge their inner workings at that level, they'd be more concerned about what needs to be done, who the contact persons are and how the process to determine which features are done when is setup. Commented Oct 24, 2020 at 5:55
  • 1
    It seems to me that you'd want to have c = n(n-1)/2, since the current formula (c=n(n-1/2)) would imply that for a team of 3, there are 7.5 communication channels. The formula n(n-1)/2 also makes sense since you have n people who can communicate with n-1 people (everyone but themselves), which should still be divided by two because currently Josh talking to Emily and Emily talking to Josh are both counted as seperate communication channels.
    – Poseidaan
    Commented Oct 25, 2020 at 12:29

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.


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.

  • 1
    What you say is just "people figured out that self-organization is a better way". But why is it better? What impediments do managers cause?
    – Daniel
    Commented Oct 23, 2020 at 16:03
  • 2
    It's not so much about managers causing impediments, but about hierarchical management of the work. When you have a traditional project management setup, you have managers in charge of lots of aspects of the development, an arrangement which can easily slip into command and control. This has all sorts of disadvantages for knowledge work, with one major one: managers (who can't do the job) tell developers (who do the job) how to do their jobs => ineficient
    – Bogdan
    Commented Oct 23, 2020 at 18:11
  • 2
    Adding to the comment above, hierarchical distribution of work only works efficiently when you have reasonable understanding ahead of time of how much effort is required to complete each task. Real-life software development (and in fact almost all engineering work) quite simply doesn’t meet that criteria because there are too many random variables involved. Self-organized teams managed through scrum don’t completely solve this issue (it’s still hard to split up work when you don’t know how much effort it will take), but they put the decision making in the hands of those who best understand it. Commented Oct 24, 2020 at 1:51
  • In most scrum(y) teams I've seen there actually was a manger, because the devs typically had no interest to all deal with customers, setting up meetings, shuffling tickets in and out of the spring etc. But the important part was that the mangers rather serve the team than the team serving the manager. Commented Oct 24, 2020 at 5:53

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.


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.


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.

  • There are non-Scrum Agile frameworks like DSDM that include formalized Project Manager roles, and there are definitely customers (especially government customers) who care about your project management process, potentially to the point of mandating that anyone who wants to do contract work for them must use a particular PM framework such as DSDM and/or Prince2. I'd downvote this Answer as a result, if I had the Reputation on this SE site to downvote.
    – nick012000
    Commented Oct 25, 2020 at 9:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.