How many dysfunctions does your Scrum team exhibit?

If you say your team does not exhibit any dysfunctions I have to ask you to revisit your thoughts again as that is so very highly unlikely. Most if not all teams exhibit some dysfunction some of the time, if not all of the time. 

Merriam Webster defines dysfunction as 

• impaired or abnormal functioning

or

• abnormal or unhealthy interpersonal behavior or interaction within a group

I think both of those definitions work well with regards to a Scrum team. In Patrick Lencioni's book The Five Dysfunctions of a Team he tells a tale about the five dysfunctions that a team typically struggles with followed by a discussion of how to address them. As a scrum master it is well worth the time to read it. As far as I know the author was focusing on management teams when he wrote it, but without very much tweaking, all the same dysfunctions and corrective actions apply to a Scrum team as well. 

The five dysfunctions are laid out in a pyramid. The reason for the pyramid is that if a team does not address the dysfunctions represented by the lower levels of the pyramid, the team will almost certainly experience some measure of the dysfunctions represented by the levels above it. Most teams experience some of all 5 dysfunctions, in my experience the extent that a team experiences each dysfunction in not linear, meaning that a team may experience a dysfunction at a lower level less and a higher level more, or in some cases visa versa.

The words inside of the pyramid describe the dysfunction that a team experiences. The words outside on the right reflect how the team will act if they do not address the dysfunction. Here is a brief discussion of the dysfunctions focusing on a Scrum team perspective.  

Absence of Trust - This is about vulnerability based trust. This is the most important aspect in building a Scrum team. It is difficult for any of us to share what we are not good at or what we need help with because it conflicts, in our minds, without need for self-preservation, for continuing to have a job. Scrum team members need to know that their teammates have their back.

The key Scrum value in building vulnerability based trust in a team is courage. The team members need to have the courage to trust their teammates. Without some level of trust it is impossible to build a performing Scrum team. A team is exhibiting vulnerability based trust when team members are willing to share things that make them slightly uncomfortable but that are helpful to the team to be aware of. For example being open about mistakes when they are made or weaknesses in skills, it is hard to admit we made a mistake or that we don't know how to do something.

Teams that exhibit vulnerability based trust are very good at taking constructive criticism from each other. In the presence of this dysfunction team members act as if they are invulnerable. They do not ask for help and any camaraderie in the team is not the friendship of a tight team, but more the politeness with someone you just met at a bar. 

Fear of Conflict - When a team that exhibits this dysfunction has a passionate debate among themselves, for example about the proper technical direction to take, they are most likely thinking of the next thing they are going to say to win the argument instead of listening and considering each other's point of view. This does not move the team forward to a solid decision. Debate and constructive conflict on a team are healthy, whereas this dysfunction is not as it prevents healthy conflict, meaning health heated discussion.  

When a team has a fear of conflict they will often not engage in the debate and experience a false sense of harmony, they will then grumble behind each other's back that a bad choice was made, leading to further team dysfunction. Hopefully it is fairly obvious that a team that is experiencing an absence of trust is more likely to also experience the fear of conflict.

Lack of Commitment - Commitment does not mean consensus, it means having some team members buying into a choice that they do not agree with because it is the direction the team is taking. When this occurs, the choice must be very clear so that the whole team can pull in the same direction. When the team does not have buy-in and the clarity needed to remove any assumptions about the direction, there is ambiguity. If a team cannot have a healthy debate due to a fear of conflict, it is unlikely a team member will be able to commit to a direction that they disagree with, as I mentioned above. It is more likely that they grumble and cause dissent, which will in turn lower the trust on the team.

For example when a team does not have consensus about the technical direction to take, everyone needs to understand what the decision exactly is (clarity) and why it was made over the other choice (this helps with buy-in). Otherwise the direction is ambiguous and vague and the resulting work that the team produces will be sub-standard and probably take much longer than needed to complete the work.

Avoidance of Accountability - How often have you thought about a teammates work, "well that isn't quite how we agreed on it, but I don't want to be mean so I won’t say anything this time." If you have ever done that, and we all know we have, you have done your team and your teammate a disservice. You have avoided accountability and by doing so you have inadvertently removed a rule from the team's rulebook. Rules are either important and have guidelines on when they apply, or they aren't rules. For the rules in the team's rule book, the team members are the only ones that will police the rules, and if they don't then it isn't a rule. 

If as a team we agree that all code will be reviewed by at least the author and 2 other people and someone checks in unreviewed code and isn't called on that when people find out, why should they avoid doing it again? It is obviously not exactly a rule if it is not consistently applied. Yes, there may be exceptions, but then they need to be well understood. 

When a team removes many or all of their rules their standards become low. If there are no quality rules, they will produce and release code that is buggy and hard to maintain. It doesn't matter if the rules are written down or just known to be rules, they need to be adhered to. When a team has members who are uncomfortable calling out their peers, the PO and scrum master as team leaders need to exhibit the behavior of calling people out so that the other team members see that this is ok, expected, and accepted.

Inattention to Results - A really effective Scrum team focuses on whatever they are currently doing, in each of the Scrum ceremonies they focus on the task at hand. When working on a story they focus on how to get it to Done! If they instead worry about what is better for them personally to do from a resume building standpoint or promotion standpoint, they are more worried about their status and/or ego. 

"Wait, I'm a developer not a QA person" I have been told and I have had to explain to many developers why QA is the team's job and that we all need to write tests, or documentation or do whatever it takes to complete the current story in progress. Our goal as a team is not write as much code as we can, but to complete and ship as many stories as we can, of course with the correct quality. The best Scrum team members are generalized specialist,  they are really good at a some things but are willing to spread out and try other things if it helps the team get the current story to done.

Teaching some team members to focus on the team and not themselves is a difficult task. When they finally see the value in either taking a task from the ToDo column and/or seeing if they can help anyone else on the team, before just starting coding the next story that is always a win.

These five dysfunctions are impediments to the team achieving its true potential, some teams never achieve their true potential, often due to how heavily they exhibit some of these dysfunctions. None of these dysfunction are things the team can address once, fix and never worry about again. A great team will continually look for and guard against dysfunctions. I have helped teams learn to see and fight against these dysfunctions, it is not something that can be done overnight, but is something that is well worth doing in building a solid well-formed team.

A well-formed team is more than just a team with all the technical skills needed to complete the job, they are a team with all the soft skills they need to operate like a well-oiled machine. If you have ever had the pleasure of working with such a team you know how much fun it can be to show up to work every day.

Stay Agile.