Non Violent Communication applied to Retrospectives
Non Violent Communication (NVC) helps us to avoid violence in our language and speech. What would be considered violent? Blaming or diagnosing faults in others or ourselves. A path to misunderstanding, conflict and suffering. In addition NVC puts a huge focus on the helpfulness of expressing our feelings to others.
We can apply NVC to the retrospective. A retrospective is session at the end of the software development cycle. Often found in teams using the SCRUM framework. The team will get together to recap what happened in the last iteration and how to improve in the next iteration. A cycle of continuous improvement. Inspect and adapt.
When we talk about issues and possible improvements in our way of doing things it is easy to stumble into communication pitfalls. One misunderstood sentence or word and we slide towards conflict instead of solving the problem.
The following is an attempt to avoid at least a few of the countless pitfalls.
Expressing evaluation instead of clear observations
Taking the sentence
“The developers never follow the designs we provide to them”
The above could have been stated by a UX designer. Using the word “never” is not helpful and forces the recipient into a defensive position. The developers in our case. An outspoken developer could counter with an argument such as
“Of course we don’t follow them. They are way too complicated to implement. And you haven’t even provided the designs for mobile!”
A sure way to incite a conflict. Why? Because the sentence is an evaluation of the developers behaviour. What would be the response more likely.
“Thanks for telling us. Let’s get together and have the designs less complicated. As for mobile we will provide them the next day and remember it for the future.”
or
“Why would we provide a design for mobile? You don’t even follow the designs for web!”
Likely playing the blame game.
Using clear observations the statement can change to
“The developers did not follow the design we have provided for the login form”
Even better if an observation of how it makes someone feel is provided
“I feel sad and redundant at points where my design input is ignored”
How probable is it to get a defensive response to the above? The probability of getting a response which gets us closer to resolve the issue is way more likely.
Thus it is helpful to express clear observations instead of evaluation.
Confusing prediction with certainty
One of the developers mentions the following to the Product Owner
“If we don’t spend a whole lot more time on testing and refactoring instead of adding new features we will not be able to ship any working software in the future!”
The sentence displays certainty when in fact it’s a prediction of the future. The estimated probability is high. Not certain.
Stated as a prediction
“If we don’t spend more time on testing and refactoring our ability to ship working software will decrease”
Putting our feelings into it
“I fear if we don’t spend more time on testing and refactoring our ability to ship working software will decrease”
Again, the likelihood of resolving the issue of not having time for refactoring and testing is increased.
Displaying a lack of responsibility
We often have more choices than we think. Quite often the responsibility for some condition is transferred to someone else or another group.
“We had to implement the feature because management forced us to do it. They did not listen to any of our arguments!”
There might be more to the story. Did we really provide the best arguments we can? If we did, would the following acceptance of responsibility be closer to the truth?
“We had to implement the feature because we want to keep our jobs.”
Maybe it is… What about
“We had to implement the feature because we were tired of the discussion surrounding it and just wanted to get it over with”
Another maybe. Though it is accepting responsibility. Being truthful to ourselves and others.
Expressing what we do want. Not what we don’t want.
Telling others what we don’t want is often felt as a critique.
“I don’t want to be questioned for decisions on what features to implement!”
The above will lead to defensiveness in others. They believe they are being talked to directly. They might have questioned the author of the statement in the past.
An addition, we can’t remember all the things we don’t want. The amount is probably infinite.
“I want an espresso”
is a whole lot easier than
“I don’t want a soda, I don’t want an americano, I don’t want black tea, I don’t want a beer, I don’t want a glass of milk …”
We get the gist. The initial statement could become
“I want to decide the direction of the product.”
Candid. But hard to get empathy for it
“Questioning the decisions subtracts from my need to feel appreciated.”
Better.
Making sure to acknowledge the difference between requests and demands
Sometimes demands are formulated as a request to appear less harsh or controlling to the recipient. The downside is leaving the recipient to ponder whether it was a request, something he could do, or a demand, something he has to do, in the first place.
Taking a demand as a request will lead to the possibility of not following up on it due to its perceived optionality. On the other hand taking a request as a demand can lead to submission or rebellion. Both are not something we strive for in teamwork.
One way to avoid confusion is to avoid unspecific language. “Should” or “supposed to” in a sentence is easily misunderstood as a demand.
“We should write more tests”
or
“Aren’t we supposed to write more tests?”
While one side goes away with “Ok, now the others will write tests” the other side sticks to “Yes he’s right, we should really write tests when we have some time left”. Two different understandings. A sure way to frustration.
A better way would be to state the request explicitly and to express our feelings
“I would feel more secure if we were writing more tests for our software. I can understand how there might be some reservations against the practice and I’ll gladly lend a hand if you have some questions on how we can add tests.”
We mention how it would make us feel and offer help in accomplishing the request.
If in doubt ask people what they have heard. We can learn if what we said was taken as a demand. To sum it up:
It is helpful to:
- express clear observations instead of evaluation
- avoid to confuse a prediction with certainty
- take responsibility for your actions
- express what we do want, not what we don’t want
- acknowledge the difference between requests and demands
Always be communicating. Non violently.
For anyone who wants to dive deeper into the topic I suggest reading Marshall B. Rosenbergs book Non Violent Communication. One of the books I wish I had read a decade earlier.
Additionally there’s a great audiobook read by the author himself which I have used.
