Agile anti-patterns

Self-organization is not a goal or a means, but a vision. Self-organizing teams are the foundation for agile practices. Teams largely determine how they can best perform their work, instead of a manager who directs it.

People have different (cultural) backgrounds, habits, beliefs, interests, knowledge, skills and temperaments. Bringing people together in a team will not automatically lead to a self-organizing team. First, the dynamics between the team members must be understood in order to be able to coach and steer towards a self-organizing team.

To better understand the dynamics, anti-patterns can help teams better understand what's going wrong. If a team understands what is wrong, then those things can be avoided or fixed. This helps a team on its way to self-organization.

An anti-pattern is a pattern that, instead of a solution, gives something that superficially resembles a solution, but is not. In this blog we take a closer look at some anti-patterns.

Team waits for the leader

There are times when the scrum master or product owner are (simply) not available to guide the team. A self-directed team does not wait for help, but applies critical thinking to figure out how to proceed.

The team must learn to develop initiatives that help the project (further) achieve its objectives. They have to organize themselves to learn the necessary new skills, prioritize to deal with problems.

The team must learn to support each other in a timely manner, adhere to general quality processes, strive for continuous product innovation and regularly share knowledge with each other on the job.

By doing these activities without waiting for a leader to tell them, the team will become more successful in both the product and the team.

Teambuilding without involving the team

The manager decides who is added or left from the team without involving the team itself in the decision-making process. Building a high-performing team is not accomplished by simply shuffling people.

There is a reason why teams that perform well have hardly changed their composition for a long time. Every self-respecting Agile organization recognizes this.

The best thing the manager can do is involve the team in all decisions that may affect team composition.

Authorities in the team

Agile teams often consist of senior and junior members from different disciplines. When disagreements erupt, senior members often impose their will on others, putting themselves above the other by pointing to their experience and knowledge. When this happens, it can lead to the wrong priorities within the team.

Especially the junior members often ask the right questions and come up with fresh ideas. Often they are insufficiently able to put this forward well and unwittingly give in to senior members, who put forward their arguments more forcefully. These behaviors hinder the building of a self-organizing team.

It is important to maintain a "no level, no label" policy in the team, where no hierarchy is encouraged. Everyone in the team is equal and the team as a whole is responsible for the end result. In this way, the team can come together as a unit to openly express their views and participate in decision-making. Above all, teams need to have patience and empathy for junior members to help them contribute in any way they can.

Freedom of expression and a sense of equality contribute to the self-organizing nature of the team.

Visible bias in the team

Based on common interests, type of personalities and cultural backgrounds, it is easy for team members to form informal groups within the team. Within these groups, team members stay within their own comfort zones.

For example, a team member finds comments on another person's code reviews exaggerated, so he looks for other people who review the code less critically. Or a developer only wants to work with one particular tester, because the other tester in the team is too arrogant according to that developer.

These preferential treatments and informal groups hinder the team's ability to organize itself effectively.

People need to be coached to work with everyone inside and outside the teams, regardless 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 build a working relationship with members across the project.

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

Putting tools above communication

Often, having efficient and useful tools is the first to be addressed. However, there is a danger that the team will optimize the wrong things with this approach.

In many cases, the right communication is more important than having the right tools, because the main cause of the gaps often lies in the right coordination and communication.

When transitioning to a self-organizing agile team, the first few iterations are full of learning from all kinds of aspects, such as operational concept, application architecture, tools, customer interactions, dealing with stakeholders, compliance with organizational and customer policies and the agile way of working.

In that first phase, the real gaps in the team's communication, coordination and collaboration are exposed in that struggle. All the ways the team has tried to establish good communication, coordination and collaboration should be discussed during each retrospective in order to maintain the effort that is working well and eliminate unnecessary effort.

Own habits and beliefs over team agreements

Team members deviate from the team's work arrangements when their behavior is determined by their own beliefs and habits.

For example, some members may request that the morning stand-ups be moved to the afternoon, as they cannot always start work early. Some believe in rushing to clear backlogs at the expense of meeting quality processes, as the perceived short-term increases productivity. For example, some find physical boards a better way to organize their work because they are not comfortable working with kanban board software and therefore do not update it regularly.

These deviations from previously agreed agreements create discipline problems that reflect a poor state of self-organization.

Use examples of Scrum values such as commitment, focus and courage to teach teams to be flexible and to act in line with agile principles. The results won't come overnight, but with continued effort, empathy and patience, your team members can all align on an approach that works.

Not following up on improvement actions

Through retrospectives, teams can come up with improvement actions based on observations from previous iterations. How seriously members take the action items and make improvements is a measure of their self-organizing behavior.

There are many reasons why a team does not create or execute improvement plans, such as not having enough time to work on improvements, improvements with dependencies beyond the team's control, lack of motivation to improve, not seeing immediate benefits from previous improvements or teams that are just not interested in improvement. These reasons must first be understood before they can be addressed by the team.

Want to know more?

Agile in Focus has a lot of experience in setting up improvement plans for large and small organizations. At Agile in Focus we are committed to help your development organization to be competitive in a rapidly changing market. We can advise and coach you in this regard. You are welcome to contact us.