Self-organizing teams are a tenet of truly agile software development. Self-organizing teams choose how best to accomplish their work, rather than a manager or someone else outside and above the team directing them.

There is a lot of advice for leaders on how to build and encourage self-organizing teams, including early project orientation, establishing commonality of purpose, removing command-and-control structures, and creating a safe environment. But sometimes, despite the prescribed methods and best intentions, teams can’t break through their ingrained customs to embrace self-organization.

People have different cultural backgrounds, habits, beliefs, interests, capabilities, knowledge, skills, and temperaments. When put together on a team, they can’t always be governed by a rulebook to become self-organized. On the contrary, the dynamics among them have to be understood to recognize the anti-patterns first.

Here are some of the anti-patterns that must be avoided and remediated to help teams move toward self-organization.

Authoritative behaviors

Agile teams often consist of senior and junior members from different disciplines. In the event of an argument breaking out, senior members often impose their will on others, citing their experience and knowledge of the subject areas. When this occurs, it sets the wrong precedence for the team.

My experience with teams has been that the junior members often raise the right questions and come up with fresh ideas, but many times they are not able to articulate them well and give in unwillingly when senior members put forth their arguments forcefully. These behaviors hamper the building of a self-organized team.

It is important to maintain a “no level, no label” policy in the team, where no hierarchy is encouraged and no one carries a label of being a SME. This way the team can come together as a unit to openly express their views and participate in decision-making. Teams should especially exercise patience and empathy with junior members to help them contribute in every possible way.

Freedom of expression and the sense of being an equal contributor adds to the self-organizing character of the team.

Manifest partiality

Based on common interests, personality types, and cultural backgrounds, it is easy for team members to form informal silos within the team to live within their comfort zones. One of my team members told me that he finds code review comments by a certain individual exaggerated, so going forward, he wanted another person of his choice to review the code. In another example, a developer only wanted to work with one particular tester, as she found the other tester on the team to be arrogant.

These preferential treatments and informal silos hinder the team’s ability to self-organize effectively.

People need to be coached to collaborate with everyone in and across the teams, irrespective of their differences. When silos are identified within the team, members should be encouraged to break down these walls, work together as a whole team, and develop a working relationship with members of the entire project.

Observing team dynamics, resolving disputes, and continuous course correction develop the cohesion in the team that is an essential ingredient for self-organization.

Struggles with the 3 C’s

When transitioning to becoming a self-organizing agile team, the first couple of iterations are full of learning from all angles, including technology stacks, application architecture, functional areas, environment setups, tools, access to the systems, client interactions, dealing with stakeholders, compliance with organizational and client policies, and even the agile way of working.

The initial struggle exposes the gaps in the team’s communication, coordination, and collaboration—the three C’s that impact the effectiveness of self-organization.

One of the challenges I have faced is the lack of face-to-face communication due to working on a distributed team. This significantly reduced the osmotic communication and collaboration self-organized teams must have. To address it, we use communication tools that allow us to chat through voice or video, and we insist that communication flow in a timely manner.

To ensure that our distributed communication results in action, I have the team agree on the essential workflows and the roles that everyone will play, whether it is coding, review, merging, testing, raising timely queries, or updating ALM tools. With everyone understanding their role, our communication fostered the right amount of coordination and collaboration among team members. To take our collaboration to the next level, individuals come forward to contribute in every aspect of the delivery as much as possible beyond their specific roles and duties.

The three C’s form an essential backbone for the team to stay self-organized. All the ways the team has been trying to achieve good communication, coordination, and collaboration should be discussed during each retrospective to keep the efforts that work well and get rid of unnecessary ones.

Habits and beliefs

Team members might deviate from the team’s working agreements when their behavior is driven by beliefs and habits. For example, some members might request that the morning standups be shifted to the afternoon, as they can’t always start work early. Some believe in rushing to complete backlog items at the cost of complying with quality processes because it offers them more opportunities to learn or increases perceived productivity. Similarly, some find physical boards a better way to organize their work, as they aren’t comfortable working with kanban board software and therefore don’t update them regularly.

These deviations from previously agreed-upon protocols create discipline issues reflecting the poor state of self-organization.

I use examples of Scrum values such as commitment, focus, and courage as powerful tools to teach teams to be flexible and act in line with the agile principles. Setting up one-on-one discussions and help sessions with members of the team also can be useful.

The result won’t come overnight, but with continuous efforts, empathy, and patience, your team members can all align around an approach that works.

Failure to act on improvement plans

After retrospective meetings, teams should come up with improvement plans based on the observations from the past iterations. How seriously members drive the action items and show improvements over a period of time reflects on their self-organizing behavior.

There are many reasons team won’t create or execute on improvement plans, such as not having enough time to work on improvements, improvements having dependencies beyond the team’s control, a lack of motivation or encouragement to improve, not seeing direct benefits from previous improvements, or the teams simply not being interested in improving. These reasons should be understood and addressed to help the team stick to the improvement plan.

Waiting for directions

There are times when the ScrumMaster or product owner is not available to give the team guidance. A self-directed team does not wait for help, but applies critical thinking to figure out how to move forward.

For example, a visual design might prescribe a PDF attachment as necessary but not describe what to do in the case of errors. Should there be an error if a doc file is chosen instead? Should a message be displayed on the screen that the file must be a PDF? Teams can use their knowledge of how usable software works to suggest and propose how to address these missing requirements.

The team also has to learn to drive initiatives that help the project achieve its customer goals. They must self-organize to learn necessary new skills, prioritize time to resolve issues for work-in-progress items, request and involve SMEs when necessary, support other groups and leadership in a timely manner, adhere to overall quality processes, strive for continuous product innovation, and regularly share knowledge with each other. Doing these activities inherently as a self-directed team will make your product and team more successful.