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
The exercise started out with the question “which of these four toxins do I experience most in my current Team?”. In the ensuing conversation, it was easy to identify individuals who engage in one or the other type of toxic behaviours listed above. The follow-up question was “what underlying situation is behind this ‘toxic behaviour’ and how is the behaviour itself trying to be helpful?” The startling implication of this question is that people do what they do in an effort to ‘help’ an underlying situation, albeit the wrong way. The interesting twist to the exercise came with the question “what is the toxic behaviour that I find myself favouring, and engaging in sometimes, and why do I do it?” This allows us to admit that we all engage in one type of toxic behaviour or another from time to time. By ‘owning up to it’ we allow ourselves the opportunity to find the appropriate antidotes, which, once applied, help the Team improve and mature.
Thankfully, there are suggested antidotes to the above Team Toxins, and knowing how to apply them, an Agile Practitioner can coach his Team towards effective resolution, growth and improvement. Most often than not, the language used in conversations to address team toxins is riddled with emotional judgements and frustration, which is either directed to other team-mates, or even to ourselves. However, at the heart of the proposed antidotes there seems to be a clear separation of these emotional judgements and the underlying, real needs that exist, which, essentially, require fulfilment for the situation to be resolved. Some of the antidotes proposed for further research by the audience are listed below:
- For Blaming
- Discussion using the COIN format (Context, Observation, Impact, Next)
- Soft start up
- Feed forward
- For Defensiveness
- 2% truth – what 2% of what the other person is saying might be true?
- For Stonewalling
- As the voice of the system… speak up! Let the system see itself.
- Get mediation
- For Contempt
- Personal development (contempt is highly damaging to both the giver and the receiver)
- Practice respectful communication
- Discussion using the COIN format COIN (Context, Observation, Impact, Next)
Being able to identify and address all the “bugs” that could crop up within the “people aspect” of Teams is an important ingredient in a mature agile team. It begins with a mutual agreement and the understanding that as complex adaptive systems, individuals and, more so, the teams they comprise will invariably face situations characterised by the aforementioned Team Toxins. If we all agree that it’s OK that they happen, then we can ‘get over it’ and collectively work towards the resolution. In so doing, we grow stronger, more mature, and more masterful of Teams collaborating for a common goal!
Share this Post