Imagine the following conversation between three Agile transformation leaders at a conference panel discussion:

Mr. Black: “We have decided to get rid of command and control. We will let teams self-organize so they can decide themselves how they want to be Agile. We expect great results from this hands-off management initiative.”


Mrs. Grey: “We have minimized our use of processes and tools by 65% since we became Agile.”

Mr. White: “We’re so Agile that we no longer use processes and tools. Now we only use individuals and interactions.”

Do these statements sound absurd? Can we really replace processes and tools with individuals and interactions? And do self-organizing teams really need hands-off management? I don’t think so, but let me explain…

The misunderstanding

The Agile Manifesto suggests that we value “individuals and interactions over processes and tools,” not replace with. Becoming Agile involves democratizing the organization so that teams previously managed and/or controlled by a manager will now become self-organizing. Teams will no longer be following bureaucratic management processes or using tools to coordinate work and control behaviours. Instead they will be handed over the rights and responsibilities to coordinate their own work and control their own behaviour.

To do so, self-organizing teams do not need less processes and tools, they need different processes and tools. Democratizing is not about loosening or letting go of control as a change of management style in order to “motivate” or “engage” employees. It’s about putting control directly where it can best be applied: with the people who have the expertise to make decisions on how best to do the work. The change is not a change in human relationships between manager and employees, it’s a change in structure of the system.

If we think of Agile and self-organization as “getting rid of command and control” without proper replacement, we risk also getting rid of clarity of roles and process so that we no longer know who can make what decisions (which is the purpose of a hierarchy) and what processes to follow (which is the purpose of a bureaucracy). Decisions that were earlier taken by a manager, a process or a tool will now be taken by the group of individuals and interactions also known as “the team.” So what do we replace command and control with?

The tyranny of freedom



In knowledge work, our task is always somewhat unclear. We don’t know exactly what we’re creating until we’re done. Every project is one of learning and discovery. It is from this realization, among others, that Agile is born.

Proclaiming teams to be self-organizing without formally creating clear agreements of who has the rights and responsibilities for what, we essentially create systems defined by ambiguity or lack of structure. What exactly are teams responsible for? And not responsible for? What decisions do the teams have the right to make? And how are teams supposed to make these decisions and hold themselves accountable?

The combination of ambiguity of task and ambiguity of process is the perfect cocktail for an unpredictable – and therefore untrustworthy – work environment. “Freedom” will often feel more like a vacuum of leadership and experienced as chaos or anarchy. In these environments, anxiety, confusion and fear will begin to spread. How will anything get done?

To overcome their collective anxiety, teams often find themselves swept up in shared emotional modes that offer instantaneous satisfaction. These emotional modes manifest themselves by team members acting as if they’re agreeing on a basic assumption about what they are there to do. These assumptions are usually outside team member’s awareness and teams caught in emotional modes will be disoriented about time, have poor memory and will not consider the consequences of their activities. In basic assumption mode, team members pointing out what’s really going on will often be ignored or silenced.

See Table 1 for an overview of the most common basic assumptions.


Table 1: Common basic assumptions that teams will adopt collectively and unconsciously in ambiguous, structureless and laissez-faire work environments. Based on the work of Wilfred Bion.

To observe the suffering that team members are going through when their team is operating under a basic assumption can be painful. It can be tempting to focus on individual behaviour and conclude that the observed dynamics is created by certain individuals where in fact what is observed is that the collective anxiety is expressed more visibly through some individuals than others.

Conclusions such as “self-organization doesn’t work”, the teams are “immature” and “it is better for everyone if management takes back control” are easy to draw. And for a manager with good intentions and that has team members’ well-being at heart, taking back control will often seem like the right thing to do. To do so will often be an easy adjustment, since no formal structures were ever changed anyway. Unfortunately, by doing so, the work environment now risks becoming even more untrustworthy as the temporary-experiment-like nature of the “initiative” becomes apparent.

Individuals and interactions supported by processes and tools



If you recognize some of the signs above, then a team you know may be caught in a basic assumption. Understand that team members aren’t necessarily fighting or avoiding each other because they don’t like each other, but rather because ambiguity and anxiety has taken over. What they need is something that will increase clarity and answer “what are we here to do” and “how do we want to get there.” Teams in basic assumption mode will not be able to answer these two questions coherently. What they need is neither to be told nor be left alone, but to be supported by appropriate processes and tools which will help them answer these two questions and get back to work.

Delegation Poker is an example of an appropriate process for teams and their managers exploring and deciding on how to share rights and responsibilities for decision making. In contrast, getting into a room to “talk it out” until “consensus” (without any further process design) will most likely send the teams and managers on the express elevator straight into a basic assumption mode.

In a broad sense, a process is simply a series of steps that teams and individuals will take to achieve a particular outcome. First we do this, then we do that and so on. When the process is explicit, understood and accepted by all team members, they can focus on what they are there to do. A tool can be anything from whiteboards and Post-its to software and communication platforms of all kinds. Tools are often introduced to improve frequent processes that are long, slow, heavy, difficult or complicated and will introduce new processes for how to interact with them.

For managers committed to hand over the rights and responsibilities to their teams, realize that self-organization is not a switch to freedom. If you try, you may turn on laissez-faire instead. Teams working on becoming self-organizing will need plenty of support as they experiment and develop appropriate processes and tools that will support them to coordinate their own work and control their own behaviour.

Louise Kold Taylor

Louise believes in building relationships based on trust and she helps teams build trust and go through change together. Louise helps create the space and atmosphere where important conversations can happen and all voices can be heard in order to inspire and engage people to work more collaboratively towards their shared goals and emergent purpose. Louise is co-author of “The OpenSpace Agility Handbook” and holds a M.Sc. in Engineering, is pursuing a MA in Human Systems Intervention and is certified as Life Coach, Team Coach and Scrum Master. She has experience working with whole systems and democratic change processes from a variety of fields.

Previous post

Why a Scrum Master?

Next post

The Everyday Agilist ponders Agile Culture


    03/10/2017 at 07:55 — Reply

    Great article Louise! I have started using the terms practices and frameworks. Just other words for what you call processes and tools.

  2. Louise Kold-Taylor
    03/10/2017 at 15:46 — Reply

    Thanks Samantha! I’m using the terms processes and tools to be consistent with the Agile Manifesto.
    You guys are not just self-organizing, but self-managing right? This distinction could be another blog post…

    James Lapalme
    14/11/2017 at 18:23 — Reply

    Great. Well done. It is refreshing to hear the voice of somebody that actually has a solid understand of organisations within the Agile community. Sadly, from my experience, many people calling themselves experts in “agility” believe that coaching skills, management experience and some certifications are sufficient to help organisation succeed. I personally believe this to be wrong. Teams and organisations are more then the sum of the people involved. Yes, organisation are composed of people, but that is only part of the story. The Agile community must bring its game to next level and truly gain an in-depth understanding about how organisations can be designed and created.

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.