This is what Scrum Guide says about the members of Scrum Team:

They are also self-managing, meaning they internally decide who does what, when, and how.

But we all know that very often if we would let the team members decide who does what, when, and how, then they tend to work the way they are used to. After all, the fact that the team members do not work the way Scrum proposes is the reason Scrum introduces the role of a Scrum Master.

So, does Scrum really let people self-organize around their work?

  • 2
    The Scrum Master is a coach, not a manager. They're supposed to help the team become self-managing, not do the management for them. Needless to say, plenty of (bad) Scrum implementations just put the "team lead" into the Scrum Master role, but that's not how it's supposed to be.
    – Luaan
    Commented Aug 18, 2021 at 6:23

11 Answers 11


The best form of organizing the work is usually achieved by those that actually do the work, or in other words:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This is a response to the more traditional way of having a manager or a team lead or someone in charge telling people what to do, which sometimes comes in contradiction to how the work needs to be performed (I've seen this happen quite a few times). So that's why Scrum and Agile is about self-organization and self-managing.

It's also interesting how you phrased your question:

In Scrum, do we really let people self-organize around their work?

Many do not let them self-organize. That's one reason why many Scrum implementations are a mess, because the higher-ups don't really want to give up control. So without knowing how to do the work they keep telling people how to do the work. That is not self-organization. That is not Scrum.

On the other side though, you can't just tell people to self-organize and assume everything will be fine. If people are mostly technical and don't have the skills to self-organize then the result will once again be a mess.

The Scrum Master then is the one that should coach the team in self-organization and help them manage things by themselves. And obviously, it goes without saying that you need an experienced Scrum Master that can properly fit this coach role and knows what they are doing. Some teenager that went to a weekend course and passed a tests to become a Certified Scrum Master isn't what you need, but sadly it's what many use.


They are also self-managing, meaning they internally decide who does what, when, and how.

So, does Srum (sic) really let people self-organize around their work?

In my experience, the quote you mention is spot on: a self-organizing team can be a great experience for all involved, and produce outstanding results, with long-term hapiness of the members as a welcome side effect.

The big misunderstanding is that we can never expect every single individual to be self-managing, in my experience. The team is self-organizing; not necessarily every single member of it.

The big spiel is that in Scrum and other Agile methods you skip the classical project lead who goes around and - as a non-technical person - tells every single person exactly what, when and how to work. The role of the project lead gets diffused into the team itself.

How this, then, works in practice depends on each individual team. Some teams consist of a bunch of highly motivated and skilled (in the area of time- and self-management) people; and in that case every single person might indeed self-manage.

In other teams I have been in, there were people who simply were not able to do so on their own, but that was fine. They needed "impulses", or they outright needed someone to tell them what to do. But that someone were the other team members, not an external force.

The reaons can be plenty. Someone might just be very fresh and inexperienced; to expect that they magically figure everything out and decide what and when to work would be illusory. Someone might simply not have the motivation or skillset to do so, and in that case they can safely lean back and trust on the "process" (i.e., a Scrum board with readily made, well-refined stories) to guide them what to do, without ever caring a bit about "managing" themselves - they show up to work, work until time's up, and then stop.

Some team members need a mighty kick once in a while; i.e. some people tend to want to "play" all the time, constantly trying out new frameworks, only ever interested in "sexy" stuff, and so on - the classical problem where a project lead would have a 1:1 and probably make them miserable. This job also is transferred to the team. If everybody is trying to make ends meet to somehow finish the work towards the end of the sprint, they might have to reign in one of their own who just is a loose cannon.

The worst nightmare is if a Scrum team has nobody who is capable or willing to self-manage, or cares about what everybody else is doing. Very frustrating experience for all involved. This would be a wrong team setup and need to be addressed like other problems in this area.

So there you have it. TLDR: the team is self-managing, but not necessarily each single team member.

  • 1
    Yes, whenever I mention skills in this answer it's always about "management" skills (in the largest sense of the word, i.e. including self-management, time-management, motivation-management, expectation-management etc. ;) ). I've added your point as a half-sentence at the end.
    – AnoE
    Commented Aug 18, 2021 at 7:08

Agility becomes Scrum at the point when a self-organising team decides to start doing Scrum. A truly self-organising team can have its pick of Kanban, XP, Scrum or any other techniques. Wider organisational and management considerations will also have a say however. There may be a desire to have a common approach to prioritisation or progress reporting for example or to support teams of varying experience and ability to organise themselves effectively. One of the things that makes Scrum so popular is that it tends to do a good job of balancing considerations of productivity, freedom to organise, risk management and accountability to the organisation that pays the bills.


But we all know that very often if we would let the team members decide who does what, when, and how, then they tend to work the way they are used to.

Absolutely, which is why it is important the team understands the value of the Scrum approach. Once they understand the value then they want to do it right, and they don't then need to be continually steered away from their old ways of working.

After all, the fact that the team members do not work the way Scrum proposes is the reason Scrum introduces the role of a Scrum Master.

Once you have a team that sees the value of Scrum and wants to do it well, then the point of the Scrum Master is to help them to achieve a good Scrum approach. The team is typically busy with delivering end-user value, so it really helps to have somebody (the Scrum Master) who is able to continually focus on ways of working rather than on delivery.

As an example, imagine a team that wants to do Scrum well, but is really busy building features for an important new product release. As the team is so focused on the new features they forget to spend time preparing the backlog for future sprints. The Scrum Master recognises this problem and informs the team. The team then responds by putting a bit less in to their sprints so that they have more time to refine the backlog.


But we all know that very often if we would let the team members decide who does what, when, and how, then they tend to work the way they are used to.

I infer that you have seen, or anticipate seeing, teams not evolving. And that is a valid concern.

Most teams actually need to learn to be self-organising, self-managed and if that is the case, self-directed.

Often they do not get much organisational help in this since that is not, in the short term, seen as improving performance (which unfortunately in many cases is the sole basis for introducing or adopting some kind of agile approach in an organisational perspective).

Fortunately, Scrum, as well as XP, comes with a coach ("Scrum Master", "XP coach"). The sole purpose of this "role" is to help the team be their own coaches and continue evolving, experimenting and discovering better ways to do development.

In many organisations, though, the "Scrum Master" has taken over the responsibilities of the old team lead, or even the sub-project leader. Which is not what the role is about.

Coach the teams to become self-organising and over time, it is not done by simply saying so, you will get better teams so that we can truly "let people self-organise around their work." It will also make people more satisfied and creative, providing more effective solutions to your business problems.


When looking at how Scrum or any other Agile methodology/approach etc. is supposed to work, imho you need to read any guidance with the systems they were meant to offer an alternative to in mind. Agile is - amongst other things - a counter-approach to hierarchical approaches often present in big companies with a lot of red process tape. In this particular case, the main issue from that perspective is that the team decides who does what rather than some (remote) manager on their excel sheet assigning people based on their assumption that all developers (or QA people or designers or...) are exchangeable amongst each other, can switch from any task to any other task equally well etc. How exactly that plays out is up to the team. It could for instance be that they have established that by default Alan takes tasks of type X and Sybille takes tasks of type Y unless either is already overloaded. It could be they let everyone pick. It could even be that there is someone who assigns tasks. It is for the team to figure out what works best and re-discus that approach in retrospectives until it works well.

Btw. I see some flaws in how you understand Scrum/Agile approaches:

if we would let the team members decide who does what, when, and how, then they tend to work the way they are used to

Implies a) that scrum is forced upon a team and b) that the team doesn't know best how to work.

a) is absolutely in contrast to the spirit of Agile and Scrum! One of their core aspects (people over processes) is that you figure out with the people involved what works best rather than prescribing what works best. That may require self-aware people, but if you don't have those then Agile and Scrum is likely not the best approach to go with.

b) is also in contrast to Scrum and Agile, because, those approaches are built on iterations to learn and adapt - as a team task. The team needs to figure out how it works best. Now that might require some guidance and foremost assistance, and this is where the scrum master comes in. Not to force a process but to help the team manage the process and iteration aspects. Take away the organization overhead and let the team do what the team does best - the realisation of the product.

which brings me to:

the fact that the team members do not work the way Scrum proposes is the reason Scrum introduces the role of a Scrum Master.

The scrum master is not judge, jury and executor. The scrum master is like a pen and paper roleplay game master, they set everything up, but the player actually play the game and make it alive. If they don't agree with the ruleset, there will be no progress and they might as well decide for another game master if the old one doesn't accommodate them. In other words, the scrum master serves the team to get problems out of their way not a whip swinging motivator that tells them how fast to row.

Arguably Scrum is a perverted Agile approach or is often applied in a perverted way, so perhaps that is where the confusion comes from, but all guides I've seen so far got those aspects somewhat right at the least.

In general if a scrum master has problems with people not following their Agile process, they failed to properly convince the team of its benefits so far. Or whoever introduced it didn't make sure the team is onboard or at least open to try it out. This might be due to to short comings in the person that wanted to introduce it, it might be that the team is not open for new ideas or that the problem/general context is not well suited for an Agile/Scrum approach.

If you force an Agile approach down a team's throat, that's gonna be counter-productive. It will hardly establish an Agile mindset as the act itself goes against that mindset.


I think you're taking too literal the statement you quoted, but I also think there's a reason to that: saying this about Scrum

They are also self-managing, meaning they internally decide who does what, when, and how.

is a bit misleading.

Why? because while yes, a self-managed team decides who does, what, when, and how, Scrum's scope ends actually on the "what" and at some level on the "who" (both of which are decided on the planning meetings); the "how" depends entirely on both the kind of project/work, the company policies, the members of the team and their experience, etcetera.

And that's exactly where self-management shows its importance.

It's not that the team just does whatever they want, however they want; its that the team, based on the backlog and the upcoming deliverable, gets to decide who is/are best suited for each task, what is the most efficient order to do them, and, again, based on each one set of skills and experience, the best way to fulfill each task, all of this while complying to the local implementation of the Scrum framework - this last point courtesy of the Scrum master, who's responsible for assuring the team stays on the road.

  • What is a "startup meeting"? Did you mean Planning Meetings?
    – Sarov
    Commented Aug 17, 2021 at 13:04
  • @Sarov thanks, it's corrected now
    – Josh Part
    Commented Aug 17, 2021 at 16:51

Probably the hardest sell in Scrum is when you tell the team "you can organize your work any way you like" and they say "Okay, then we'll keep doing it this way."

Because that's also self-organizing.

What it really tells you is that your employees aren't interested in Scrum or self-management. Which means you have to first do the very hard work of changing your work culture to something that will make your employees embrace the new way of working.

It might simply mean your current company culture attracts people who just like to show up, do the job, and go home at the end. People who like the stability and like leaving work at the office when they go home. Or people who don't want to spend their energy on changing their working process. There is nothing inherently wrong with this.

It just means Scrum isn't going to help you (yet), because the values of Scrum don't resonate with the people you have.

It does show you one of the big rules of Scrum: using Scrum doesn't fix your problems, but it does make them very obvious. If you run into this situation, your problem is your people (and thus usually, your culture) isn't made for Scrum and so your employees aren't interested in it. Don't make them (that goes against doing Scrum), but instead ask yourself honestly: what are we doing that is creating this atmosphere where self-management and continuous improvement aren't resonating with anyone?


You are quite correct, @Daniel: As I often train, a team with a full-time organizer is not self-organizing.

I started with agility by creating true self-directed work teams in the mid-1990s. These teams had no team leader, and managers did not participate regularly in their meetings. Based on a seminar I took, I led them through creating a mission statement, team rules, and a light work management process. Once they had that process down, I trained them to take over the facilitation role themselves by rotating it among all members, and freed them to meet their customer needs any way they wanted.

These teams fully met the principles of the Agile Manifesto before it was written, because those principles were already well-proven by research data dating back decades. Yet they're still largely ignored even in self-proclaimed "Agile organizations." Scrum is a good shortcut to starting teams down the path. Where it violates the self-organizing concept is when an experienced Scrum Master is viewed as a permanent need rather than a temporary hands-on trainer, and when teams are required to keep using Scrum. I train teams to rotate the role, and once they are meeting initial performance standards, I switch to occasional coaching.

By the way, those self-directed teams achieved phenomenal, measurable performance improvements and customer satisfaction. Here's my reliable recipe for creating them (free and open-source, with detailed instructions): Self-Directed agile.


In my view, the thing that you are constantly fighting against is: "the lone wolf," who never in his/her professional career has never known it to be any other way. This one person is entirely accustomed to confront some new problem, and then to single-handedly produce and then deploy(!) a solution to it, without meaningfully consulting anybody else on the so-called "team."

The term, "self- directed," needs to be very-delicately replaced with: "team- directed." And, the various responsibilities – design, implementation, testing – which had once been shouldered by a single "superstar" need to be meaningfully shared among various members of the team.

Frankly, there's a certain amount of persuasion that is needed to convince a "superstars" that they no longer have to single-handedly "keep their finger in the dike." They're just not used to that idea. Yet.


As the Scrum guide says:

While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices

Scrum at all is about empiricism, where it comes from experience and observing the output, Scrum also provides its events to achieve its values and the empiricism approach, one of these value is Scrum developer commitment.

You should note that it is an incremental process and it focuses on continuous improvement, so, as your team progresses they will adapt their skills to really deliver value.

What i mean is that the trust you give to your team will lead to commitment and self scence of accountibility without being a leader and this is a continuous process every time they will enhance and achieve scrum values

It is good to be a full Scrum don't think at these moment now, think after many projects how you will find a self-managed, cross-functional and dependable strong people with your hand by hand because they learned and enhance their commitment by applying empiricism approach which done particularly at each Sprint Review and Sprint Retrospective

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