Mastering Teams & Debugging Team Toxins

In his book “Drive”, Dan Pink suggests that Mastery is one of the three elements — along with Autonomy and Purpose — that compels us to do what we do.

Mastery allows us to move from simply complying to a set of “rules” and “musts” to engaging in the functions that comprise our vocation. “The former might get you through the day,” Pink claims, “but only the latter will get you through the night!”

After attending the first Johannesburg-hosted Scrum Gathering late last year (October 2015), I was inspired to look into ways of applying the techniques shown to various aspects of Team building. Mastering Teams is a complex endeavour, and it is not surprising that at the heart of building the relationships that make or break a Team one will invariably find “communication”. I have come to believe that the degree to which communication is hampered or allowed to flow freely and transparently throughout any given Project Team is, probably, the most important predictor or determinant for its failure or success.

I have come to believe that the degree to which communication is hampered or allowed to flow freely and transparently throughout any given Project Team is, probably, the most important predictor or determinant for its failure or success.

In software development, it is considered a best practice to have adequate code coverage in terms of unit tests. Unit tests are focussed, automated tests that are used to assert the existing (current) quality of the code, but also to ensure that the constant changes made to software do not break things that worked previously. Each unit test focuses on a small piece of code. Individually, unit tests are not significant indicators of the state of the code in its entirety. However, all of them together, depending on the code coverage, give us valuable information about the state of the software after every change made to it. If a unit test fails, the development team is prompted to seek out the broken code and fix it, while adding new unit tests to guard against similar pitfalls in the future. I think we can apply this concept of ‘coverage’ in Project Team Communication. By ensuring that there is enough and properly focused communication we can ensure that things that work in the team are safeguarded and strengthened. When, however, we identify problem areas, we are able to address them, and put in place measures that help us identify similar problems quickly so as to resolve them promptly, and before they have had a chance to damage the Team’s integrity and effectiveness.

Agile values and principles, and the guidelines that emanate from them, place paramount importance on communication. To illustrate, Scrum or Kanban, albeit they differ in the way they implement the values and principles of agility, have a common denominator in that communication is at the core of these respective agile implementations. Daily sync-ups, retrospectives, product reviews, backlog refinement and planning sessions, task boards, burndown / burnup charts and cumulative flow diagrams are all devices proposed to ensure that adequate, focussed, free-flowing, transparent and effective communication is taking place among all the role-players in a Project Team.

Fixing process and collaboration problems is dealt with predominantly in the Retrospective. In their talk at the Jo’burg Scrum Gathering last year, Sonja and Wessel Blignaut highlighted this in their workshop session titled “The Team as a Complex Adaptive System and the Importance of Retrospectives.” Bugs in software are easy to address, especially when they are as black and white as unit tests suggest through their ‘pass’ or ‘fail’ result. However, with human beings, who are themselves complex adaptive systems this is a tad more challenging. We are ready to deal with things that are obviously wrong and are process-related, but how often do we willingly and comfortably venture towards addressing the so-called “white elephants” in the room, when the issues at hand involve the people themselves? When things become “personal”, it is very easy to slide into counter-productive, toxic behaviours which inhibit the Team from finding the required solutions, and in so doing, really improve.

According to Sonja and Wessel, Agile Practitioners have an important role to play in these situations too, so that their Team is enabled to create “The Smell Of The Place” that sparks energy, creativity and action to produce the best possible results, rather than the sluggishness, lethargy and listlessness created by situations of blame, contempt, defensiveness, and other such team toxins. Part of that function will invariably involve diagnosis of problem areas (white elephants) and intervention to ensure the continued optimal functioning of the system. The trick is to carry out these tasks not as an ‘expert’ telling the Team what is wrong with it, but rather as a mirror showing the system to itself and letting it decide what needs to be addressed. This way, enabling conditions are created for learning and the emergence of beneficial self-organisation.

The trick is to carry out these tasks not as an ‘expert’ telling the Team what is wrong with it, but rather as a mirror showing the system to itself and letting it decide what needs to be addressed. This way, enabling conditions are created for learning and the emergence of beneficial self-organisation.

During the workshop, a technique facilitated by Sonja and Wessel was put into practise by the audience. It was specially designed for dealing with John Gottman’s four known Team Toxins listed below, which usually go unaddressed in Retrospectives:

• Stonewalling – not open to influence, avoidance, uncooperativeness, passive disengagement, yes man, withholding
• Defensiveness – not open to influence, deflection
• Contempt – cutting others down, hostile gossip, undermining, disrespect, demeaning communication
• Blaming – aggressive attacks, bullying, harsh start-up, chronic “criticalness”, domination