5 Signs that Your Agile Team is Dysfunctional (And What You Can Do About It)

I’m sure by now, you have seen plenty of articles and papers that use sports analogies to describe the dynamics of Software teams and teamwork. Sports analogies are a great way to convey the relationship between the members of a team – how they behave together, how they work towards a common goal, how they need to each have a specialized skill but also play a different role if the team requires them to…the list goes on. However, sports analogies often do not help us figure out what to do when a player decides NOT to be part of the team.

I am fairly confident that you have (as I have) encountered plenty of instances where “team members” simply do not want to cooperate, and only look out for themselves for whatever reason, perhaps a Terrell Owens of sorts (no offense to Cowboy/49er-fans). For an Agile team where all team members are expected to function together seamlessly and collaboratively own the work, all it takes is one person who is not fully-committed to prevent your team from fulfilling its maximum potential. So what can we do to ensure our Agile team runs like a well-oiled machine?

In this article, I would like to share a few thoughts from my personal experience working in, mentoring, leading/managing software professionals over the past several years. Through my stories, I hope you will gleam some ideas on how you might handle these types of situations in the future if/when they arise.

Scenario #1 – “Only I know that code”; “I’m the best in that position”

An Agile team is optimal when the team can collaborate and help each other out as early and often as possible. If you have someone on your team who consistently “hoards” code and does not share the knowledge with other team members, this is a red flag that you should seriously consider addressing.

One of the most popular practices that have been adopted from the Extreme Programming (XP) catalog of practices is pair-programming, where two (or more) developers work on the same code side by side. This practice is intended to improve code quality as well as broaden understanding of the product being built through hands-on learning. Naturally, it requires a certain type of personality in order to be effective in this type of a setup. However, it might be worth exploring if you believe that there’s an opportunity to improve collaboration within your team.

Scenario #2 – “That’s the testers’ job” or “That’s not my job”; “I only play on special-teams”

An optimal Agile team is a team of peers that will help the team achieve its goals, no matter what it takes. Sometimes when you have a seasoned or highly-skilled team member, you may have a “star player” who believes he/she is not suited to do work that they may not customarily have done in the past, which could actually impede the overall success of team.

In my experience, high-performing technicians who have built their careers around being “the hero” are generally unlikely to change their approach to doing work. However, in this situation, you might consider leveraging the experience of this individual to help coach or train others on the team so that he/she can contribute to the greater good of the team.

Scenario #3 – “I’m done with my tasks”; “I scored 3 touchdowns in this game, and nobody else has scored any”

Helping your Agile team think and behave as a cohesive unit is not easy at all. On paper, it makes perfect sense, but in reality, many high performers are simply not accustomed to working as a team. It will likely take time for some team members to start thinking as a team instead of a group of individuals. Encourage them to see the bigger picture, look out for the broader vision and objectives of the team, which may trigger more team-oriented behavior. Do not expect habits to change overnight; we are all creatures of habit, and old habits are very hard to change.

Scenario #4 – “We can use whatever process that makes sense”; “We can call an audible at any time that we think is right, even if the coach doesn’t think so”

Some Agile teams have a tendency to feel that because they are practicing “Agile”, they no longer need to follow any process or rigor of any kind. This is a common misconception and a big risk to watch out for. If your team feels that they can customize or tailor the process any time they wish, try to channel that energy towards the Retrospective. Provide positive reinforcement for the continuous improvement mindset, but coach them to do so within the context of a structured approach within the Retrospective where the team can explore opportunities for change then make a cohesive commitment towards improving the current state. Making changes on a whim and/or without a methodical approach may result in wasted efforts or further degradation of team performance.

Scenario #5 – “We are meeting all of our goals, so why do we need to improve?”; “We have won the championship already, so why do we keep trying to trade for better players?”

The mindset of relentless improvement is not an easy thing to achieve, and many Agile teams will need several weeks (or even months) to develop this mentality. Thinking about long-term gains instead of focusing on short-term wins will typically require consistent coaching and mentoring. One technique you can employ is consistent Retrospectives to provide a forum to identify opportunities for improvement then make a commitment to follow through as a team.

In summary, improving teamwork as a high-level concept has been a thoroughly-researched subject, yet it remains highly challenging for many organizations to achieve effective team dynamics. At the foundation of all great teams is trust and respect, which take time to develop. As an Agile leader, your job is to help build the proper mindset that fosters collaboration and trust, which will ultimately lead to innovation and creativity if you are fortunate. It is my hope that you can leverage some of these analogies to sports teams to help communicate effective teamwork to your Agile teams.