Self-organized teams are fundamental to the success of agile approaches. But what does self-organization means?

5-6 years ago we started to introduce agile to CxO of multiple clients. I remember that the most unbelievable for them was a term self-organized teams. Well, it was unimaginable to see people working without any Mr. Commander. Without somebody who delegates work, knows what is expected and how to achieve that in details. Without somebody who can push people to do the work. Well, people are lazy, aren’t they?

There were even some funny moments to see CxO simulate a chaos by a mimic or gesture. Simply, you are telling us some fairytale.

10 years of Agile in practice

Well, the situation has been different for the past few years. Thanks to the progress in other areas as well. Leadership, company organization, and structures, a speed of the business and technology. It is hard to keep the pace with changes, it is hard to be the one knowing everything. People have much more options to choose a better company to work in. An interest to spend life valuable, working on interesting challenges.

The fundamental need of having a self-organized team is without further questions, it is simply a statement which every CxO understand.

Self-organization. Really?

Most of the agile teams think about self-organization as an organization without the Commander. People do what they want based on agreements and mutual understanding. That is true, but is it everything?

The real self-organization

A few months ago we were preparing a big workshop for 50+ people with the management of the company. The discussions and preparation meetings were endless. Everything had to be pointed out in details. Who, when, the agenda, topics, the sitting plan.

The sitting plan was the biggest pain. “Well, we know our people. A doesn’t like B, B likes A, but doesn’t understand why he behaves like he behaves. C want to work on X, but Y doesn’t let him do it. Z had some problems in history, so we need to have somebody to do babysitting.”

Imagine you have to draw and unwise such a web of relationships, history, knowledge and bring out the best sitting plan.

The management stuck in willingness to solve this complex problem. So we discussed, discussed and discussed. Just to make sure that everybody will feel fine. The best intentions.

Have we been successful? Of course not! Life of people preparing the meeting lost in many calls and discussions.

Finally, we had big pain that helped people to start looking for an alternative approach. What was it?


But the real one. To achieve it we set some limits for proper and efficient collaboration.

  1. Every team must be less than 8 people, ideally 4-6. So in the sitting plan, we organized tables as nests with maximum 6 chairs.
  2. Every team must work on some topic selected from the backlog of topics for the workshop. In our case, there were real-life situations like dealing with bugs, new features, support calls, etc. Every team must deliver working “products”. Topics were transparently accessible in the backlog in the front of the room printed on cards.
  3. People had 15 minutes to find the place and people they would like to work with in following 3 days. The limit created the pressure to organize fast without any necessity to push people by a Commander. The first minutes were chaotic, be patient in this case. Just wait and a dust will settle down.
  4. People then pull one topic they would like to work on from the backlog. They were aware of items upfront before the workshop so this was pretty fast. Once the topic has been analyzed, they pulled the extra one they wanted to finish.
  5. Pulled topics must be moved to In progress column on Kanban board that tracked all 10 teams. Kanban board was maintained by the team representatives.
  6. Overall progress moderated “ScrumMaster” who took care of timings, breaks, materials, and needs of coffee, coffee, and coffee.
  7. Days were split into 2 hours blocks. Every block started by the selection of the topic from the backlog and finished up with 15 minutes review of the results.
  8. Teams were allowed to use post-its and flipcharts only, so they were able to interact.
  9. The review has been done in swarms. Participant’s selected the team they would like to give a feedback. How did they know which team worked on what? Well, there was the kanban board in the front of the room.
  10. At the end of the day, we did the retrospective to understand what needs to be improved for people to feel valuable and fine. So the next day was better than previous one :).