No one tells me what to do – how self-organized teams work

Self-organized teams – the dream of every project manager (and every manager). In agile practices, they’re essential. In conventional projects, not so much. Now, I'm going to tell you how to get a self-organized team and why it usually doesn’t work that well in conventional projects (for now).

Self-organized teams don't just fall from the sky. It takes a bit of effort before a team like this can function and work efficiently. This is also why SCRUM implementations, for example, can sometimes fail. Let’s take a look at how SCRUM or agile practices are typically introduced:

1. Management hears something about agile methods and decides they want to implement it in the company. 
2. They hire coaches to guide the process and help the teams. 
3. The teams are assembled and trained.
4. The opening shot is fired, and they start using agile practices.

Granted, this is a simplified version of events, but the main points are there. Yes, I know that there are other ways to do it and that they usually end after step 1. One thing is missing, though, and it’s usually missing in real life, too: Who will guide the managers? 

If you want to implement agile practices, you need to take agile values and principles seriously and really live by them. On this, you usually read something about trust, courage, cooperation and so on. Management (the activity, not the people) doesn’t really fit the bill. If you want to use agile methods, you need to do less managing and more leading.

What does this have to do with self-organized teams? These teams need leadership! But for heaven’s sake, not management. A SCRUM team is solely responsible for implementation. They figure out how they can implement the requirements. They say how much they can accomplish in a sprint. A manager would tell the team what they have to do and how. Agile teams have to be allowed to make mistakes in order to learn. The “fail fast” approach to risk minimization is essential to agile practices. Managers usually avoid mistakes, and in the worst case, they’ll look for the culprit – or at least the worst offenders. 

But self-organized teams need someone who will lead them, who will train the team members, who will give them a framework that they can move around in and who will trust them. It would be wrong to conclude that you don’t need Management anymore. This would be a mistake. The managers of yesterday will need to re-orient themselves and become “servant leaders”. They’ll work closely with the SCRUM master or the agile coach and help clear the obstacles that hinder the team – whether it’s know-how, work equipment or framework conditions.

It can work in conventional projects, too. In agile environments, self-organized teams are an everyday phenomenon, and they work. The way that conventional projects are organized makes them more suited to hierarchical organizations. After all, there’s also a project MANAGER. What does he/she usually do? Right – tell the team what they have to do and when (and maybe even how.) Although 70 % of project management work is actually leadership work, oftentimes, only the 30 % that consists of management (e.g. organization, coordination and administration) is actually taken seriously and put into practice.

A self-organized team, once they’ve experienced management, i.e. been told what to do, when and how to do it or been reprimanded for failure is no longer self-organized.

Here are the points to keep in mind if you want to establish self-organized teams in a conventional project:

• Built your projects around motivated individuals
• Give them the environment and support that they need
• and trust them to do the job.

That’s the 5th agile principle. It tells you everything you need for self-organized teams. It takes courage to implement this principle. The project manager has to understand how a team works, how it’s formed and that it takes time. He/she needs to defend the team from the customer and from internal Management if they make mistakes or fail now and then. He/she also needs to trust that the team will learn from their mistakes. For this to work, he/she needs to create the conditions for this.

In conventional projects, a team doesn’t get to decide when they’ll do something. That’s what the project schedule is for, right? But the team can decide how they’ll do something. They’re allowed to choose who’s responsible for what. The project manager doesn’t have to assign work anymore. With time, the team gets braver. They start suggesting improvements to the process and the requirements. 

What helps is a backlog, which could be comprised of tasks in this case. At the beginning, all the tasks for an iteration are written down and posted on a task board. The team members then independently take tasks down and complete them. You could also set up a modified sprint planning meeting. This works for teams that are geographically spread out, too.

It takes a bit of a light touch and a bit more time to establish self-organized teams in conventional projects. But it’s worth it, in any case, and it pays off.