Self-Organizing Teams – 5 things you absolutely need to have your teams self-organize

Self-Organizing Teams – 5 things you absolutely need to have your teams self-organize

First of all, what does it mean to self-organize? From , self-organization is the ability of a system to spontaneously arrange its components or elements in a purposeful (non-random) manner, under appropriate conditions but without the help of an external agency. It is as if the system knows how to ‘do its own thing.’

I have heard about self-organizing teams but never really understood what that meant. It wasn’t until I had an opportunity to lead an Agile Development Support team that I actually saw it happen. I was truly amazed and excited to see it happen. It is like how someone tells you how great and grandeur the Grand Canyon is but you never really know until you see it for yourself. Let me tell you a little bit about the Agile Development Support team to give you a clearer picture. The Agile Development Support team was created to fix defects found in production. The Support Team used Atlasian’s Jira to track and manage defects. You can equate defects to user stories and we treated defects as they were user stories. Defects like user stories were prioritized and estimated. Our backlog instead of user stories consisted of defects. Defects were ranked according to priority and value. The Support Team consisted of a mix of developers and testers. They ranged from junior to senior level. The Support Team individuals knew each other and had worked with each other in other projects. The Support Team had a scrum master.

The self-organization occurred in the fifth week after forming the Agile Development Support team. I came into our morning scrum and the team started to discuss what defects should be worked on next. The conversations were candid and hard questions asked. The team really wanted to work on defects that were the most valuable to our customers. Once the team selected several defects to work on, developers volunteered to work on the defect. Testers volunteered to test defects. They selected what to work on. We did not have to encourage them to do so they just did it. The team committed to getting specific defects fixed, tested, and released to production. The Scrum Master did not have to poke or prod the team members to do anything. The team wanted to do it and get results. The team had very open communication. People on the team were not afraid to ask questions if further clarity was needed. People were not afraid to push-back or say no if it was the right decision to do so.

I have worked on other teams but this team was the first that I really saw it occur. I became curious as to why some teams do not realize self-organization and others do. I arrived at the following conclusion about self-organization. In order for a team to self-organizing the teams needs the following:


1. Understanding of an end goal

It’s very hard to succeed in something if you don’t know how to measure the success. The military excels in communicating what is defined as a success and a failure. Each military task has an objective to accomplish. Either the objective is met or not. Likewise, a team needs to know success criteria. They need to know the purpose for team and reason for their existence. The Agile Support Team, when it was formed, defined a purpose and reason for their existence. The Agile Support Team existed to quickly triage and resolves the most critical defects that our customer had. The team was to allow the development enhancement teams to continue to develop enhancements. Each person on the support team knew this objective and they committed to it. The Agile Support Team had defined SLAs (Service Level Agreements) – how quickly tickets should be resolved based on severity. The team used this to constantly measure how they were doing each day. This evolved to having large screen monitors in the hall way that displayed ticket metrics.


2. Clear processes

Initially, the team did not have clear processes and this caused the team to waste time in trying to identify what to do. There was effort lost in trying to determine processes than actual work. A team will have a hard time self-organizing if they don’t understand communication channels, how to interact with other teams, escalation processes, development processes (i.e. code check-in policies, approval requests, final decision maker, code reviews). Once the team, understood the processes, they were more comfortable and more focused on the work at hand. If an issue or challenge appeared, they knew what process or guideline to follow to help them overcome the challenge. They spent less time “spinning” – trying to determine what to do next.


3. Consistency

Consistency is important to a team. Processes should not change very often and the team should assist in defining the process and changes to the process. Likewise the team should know each other. They should have worked with each other for some period of time. When a person has worked with another person, that person knows likes and dislikes with that person. They know their strengths and weaknesses and can better compensate for weaknesses.


4. Empowered to self-organize and manage their work

Each member of the team should have the authority to self-organize and manage their work without interference. I have discovered that most teams do not self-organize because they are not truly empowered to do so. The Scrum Master might be too controlling and making all the decisions that the team can make. The team needs to know that they are allowed to self-organize and manage their own work. Management should play a supportive role and encourage team decisions instead of management making the decisions.


5. Competency

The team should be competent in what is asked of them. Each team member should have basic competencies. If a team does not have the competency they will fail. It is the responsibility of leadership to assemble teams that can be successful. Team members should assist each other to succeed ensures each other has the right competency. In self organizing teams, you may find less competent members voluntary remove themselves from the team or find employment elsewhere. In a team environment, strong skilled individuals stand out and so do the weaker skilled individuals.


Looking back at the support team, it probably took 5 weeks for the team to self-organize because we did not meet 2, 3 ,4 above. Initially, the team did not have clear processes.  We spend a lot of time discussing and establishing processes. The team needed to build some consistency. We did not have processes that people knew. Also, the team needed some time to rebuild a working relationship with each other and understand team dynamics. Early on, the team did not know they were empowered to self-organize and manage their own work. No one said they could not but no one said they could. It took several weeks for them to get confidence and just do it.

Alden Mallare

Alden Mallare

Hi there. My name is Alden Mallare and I am currently a Software Development Manager. I've been in the software industry for over 15 years with experience in software development, software management, test management, and test automation. I am passionate about Agile and consider myself as an Agile Evangelist. On the side, I help churches build awesome websites. I also created MusingMashup.Net to share my thoughts and hopefully help others through my writing.
Alden Mallare

Latest posts by Alden Mallare (see all)

Leave a Reply

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