The organization

The Developers: an autonomous, self-organizing team

In a Scrum Team, the Developers are the people who build the product, and they are the ones who decide how to go about it. Three patterns from A Scrum Book describe this small team, the way it organizes itself and its independence from the rest of the company. The 2020 Scrum Guide has since changed the vocabulary while keeping the idea.

The Monday morning schedule

A long-distance bus company is rebuilding its booking website. Five people work on it: two developers, a tester, an interface designer and a database specialist. Every Monday the project manager, Marc, hands them a table in which every task for the week carries a name.

On Tuesday, Inès finds that the schedule service returns dates in an unexpected format. Her task is blocked. "I'll let Marc know," she says. Marc is in meetings until Thursday. In the meantime Inès starts on a task planned for the following week, the tester has nothing to test and, by Friday, no feature is finished.

Three months later the organization has changed. On Monday the Product Owner (the person who orders the list of what needs to be built) presents what she expects from the next two weeks and why. The five then decide among themselves who starts on what. When the date problem comes up, Inès raises it the next morning at the team's daily meeting. Thomas, the tester, answers: "I've seen that format before on the old system. Let's work on it together this morning." Nobody asked for permission, and the feature is finished on Thursday.

Development Team: five people around a product

A Scrum Book (2019) describes Scrum as a set of patterns: each one sets out a recurring problem, the forces pulling against each other and a solution drawn from experience. The Development Team pattern carries two stars, the rating the authors keep for solutions they believe a Scrum team will end up needing.

The problem. Many achievements are beyond what one person can do alone, and teamwork is what gives production its greatest strength. The question is how to connect individuals so that they form a whole without losing their identity.

The forces. A brilliant individual can create a good product, but lacks outside eyes to spot their own mistakes, and it is hard to grow from a single person afterwards. Conversely, a group that is too large only reaches agreement after long discussions, and every newcomer first slows the others down: the book gives, as a rule of thumb from James Coplien, a loss of about a quarter of productivity for six months. Finally, work with the market plays out over months, while building moves in weeks or days. Giving both to the same people puts them under strain, which is why the Product Owner is kept distinct from the team that builds.

The solution. The organization forms a stable team of about five people, located in the same place, who gather around the product the Product Owner wants and deliver successive versions of it. This team is autonomous: its members chose to belong to it, and it organizes and manages itself. The Product Owner can tell it, in substance, that the product is theirs and that building it is up to them.

The book calls all the members "developers", whatever their trade, to avoid labels. Each person belongs to a single team. The team has no subgroups and does not work like an assembly line where the work passes from station to station: there is no separate test team. It brings together the skills needed to finish its work, or the willingness to acquire them. Scrum tradition spoke of seven people, plus or minus two, but the authors observe that effective teams are smaller and that the best sometimes have only three developers.

Self-Organizing Team: the team decides how it works

The Self-Organizing Team pattern (two stars) deals with the inside of the team: who does what, in what order and with whom.

The problem. No way of organizing a team and its work is right for every situation or valid forever.

The forces. Any work done by several people needs coordination, or disorder sets in. To keep things simple, organizations adopt standard structures and "best practices". These were born in a specific context, which is not necessarily the team's, and they age as the situation changes. Many people find it comfortable to be told what to do, but the book points out that motivation suffers under management that controls everything, and that those who do the work are best placed to improve it. Finally, if everyone stays within their specialty, tasks wait while other people are free.

The solution. The Developers organize themselves to finish their work, and they alone are responsible for how they do it. They run their daily meeting, decide who works on what and in what order, choose to pair or to gather several people on the same item, and make use of everyone's skills.

The authors warn that this self-organization takes maturity and discipline. The Product Owner and the Scrum Master (the person who helps the team practice Scrum well) are tempted to step in when the team hesitates. Yet the Scrum Master never assigns tasks and never tells the Developers how to work. Another danger appears when the boss disappears: a team member takes the boss's place and imposes their will through charisma, intimidation or by monopolizing the conversation. The Scrum Master then helps the team see what is happening and put it right.

Autonomous Team: the team decides without outside control

The Autonomous Team pattern (two stars) concerns the boundary between the team and the rest of the organization. The book also gives it the name Self-Managing Team.

The problem. When it comes to rules and procedures, one size does not fit all. Each team has its own people and dynamics, and the team that carries a responsibility, with the skills it calls for, knows better than anyone how to go about it.

The forces. Stakeholders have a stake in the product's success and feel safer if they can direct the detail of the work, even though they know it poorly. The structure around the team wants to impose objectives on it, or "best practices" shared by all teams. Every intervention sends the team the message that it is not trusted and sets up an opposition between "them" and "us". The book adds that decisions made on the spot are more effective than those imposed from outside.

The solution. The Scrum Team (the whole team, with its Product Owner and its Scrum Master) makes its decisions without outside control, while staying attentive to its surroundings. In the same way, the Developers govern themselves during the part of the Sprint devoted to production. The Sprint is the fixed-length working period, one month at most, that sets Scrum's rhythm.

This autonomy has limits. If the organization has chosen Scrum, the team follows Scrum, and it acts within the organization's values and goals. Autonomy goes hand in hand with accountability, since the team has the authority and the responsibility to reach the Sprint Goal. It keeps its work visible and submits it to outside eyes at the Sprint Review, the end-of-Sprint meeting where the result is examined with the stakeholders.

On this point the book cites a study by Ethan Bernstein (2012): factory workers feared that being seen fixing a defect would draw management's intervention, and quality improved when they worked out of sight. The authors therefore invite you to think before adopting a tool that lets management track every defect.

From the book to the 2020 Scrum Guide

The book, published in 2019, cites the 2016 edition of the Scrum Guide by Ken Schwaber and Jeff Sutherland. The 2020 edition changed several points that bear on this article.

• The term "Development Team" disappeared in favor of "Developers". The Guide wanted to remove the idea of a team within the team: there is only one Scrum Team, with no sub-teams or hierarchy.
• The Developers are accountable for four things: creating the plan for the Sprint, called the Sprint Backlog, instilling quality by adhering to the Definition of Done (the shared definition of finished work), adapting their plan each day toward the Sprint Goal, and holding each other accountable as professionals.
• The adjective "self-organizing" used in earlier editions became "self-managing": the Scrum Team decides internally who does what, when and how. The Guide applies this word to the whole team, Product Owner included, whereas the book splits the idea between two patterns.
• On size, the Guide states that the Scrum Team is typically ten people or fewer, Product Owner and Scrum Master included. It says nothing about the workplace or about how members join the team.
• On substance, the agreement is complete: the Guide specifies that how to turn an item of the list into a usable result is up to the Developers alone, and that nobody else dictates it to them.

Limits and pitfalls

The first pitfall is autonomy that is proclaimed but not granted. The organization announces that teams organize themselves, but a manager keeps handing out tasks, sometimes through the Scrum Master. The Developers soon understand and wait for instructions, as Inès waited for Marc.

The opposite pitfall is abandonment. Telling a team it is self-organizing without giving it a clear goal or an available Product Owner leaves it to fend for itself. The three patterns assume a frame: a Vision, an ordered list, known rules and someone who shields the team from interference. A beginner team often needs close support, and in that case the book recommends the help of a coach rather than the return of a boss.

This way of working does not suit everyone and does not remove outside constraints. In a hospital or a school, regulations are not up for negotiation, and autonomy concerns the way the goal is reached. A highly autonomous team can also become blind to its own weaknesses, which the book addresses with the Pop the Happy Bubble pattern, presented in the article on the Scrum Master.

As for evidence, the book cites a few studies from work psychology on the effects of autonomy. It also repeats spectacular productivity gaps between teams, up to 2,000 to 1, taken from a book by Jeff Sutherland which itself relies on data from Lawrence Putnam and Ware Myers. Such figures should be treated with caution, and the article Criticism and the state of the evidence returns to them.