In this article you’ll learn about agile retrospectives, the basic principles of Non-Violent Communication (NVC), and how applying those principles to a retrospective can improve the retrospective.
If you’re already familiar with agile retrospectives, you can skip the sections explaining it.
What is an agile retrospective?
An agile retrospective is a meeting format, commonly used in software development, but also suitable for teams outside of software development. Its main purpose is the continuous improvement (Kaizen) of processes, collaboration and work itself. Other benefits are knowledge sharing and building trust and community inside the team.
The team holds retrospective in regular intervals (e.g. bi-weekly, monthly, quarterly, etc), evaluating the past interval, how things improved compared to the last previous interval and figures out actions for improving the next interval.
What does an agile retrospective look like?
Side note: There are many variations of the format, I’ll describe the format that I like best.
The agile retrospective meeting should have a facilitator who explains the purpose and format of the meeting, keeps an eye on the clock and the talking time of the participants and maybe also takes notes. Ideally, the facilitator is not an active participant. The facilitator guides the meeting through the following phases: Brainstorming, Prioritizing, Discussion and Review.
Brainstorming
The facilitator presents the retrospective questions. The questions should focus the attention of the participants. The facilitator explains that the focus should be on the time span since the last retrospective. Typical questions are
- What went well?
- What didn’t go so well?
- What have I learned?
- What still puzzles me?
Another set of questions could be
- What should we keep doing?
- What should we add?
- What should we do less?
- What should we do more?
Or
- What were the anchors? (Things dragging us down)
- What were the engines? (Things propelling us forward)
All participants write down things or events from the retrospective interval that answer the questions, using sticky notes, a sheet of paper, or retrospective software. Each note should be only a few words long. Each participant working on their own has the benefit of not forming a consensus too early, reducing the influence of the more vocal people in the group and getting input from more withdrawn personalities.
The participants then gather and present their findings, explaining their notes in one or two sentences and assigning each note to a retrospective question. In bigger groups there might be time constraints like “max. 2-3 items per person” or “2 minutes of speaking time per person”.
There are several ways for the participants to present the answers to the questions: Do they want to start with the more positive items, to get into a joyful celebration of successes that helps dealing with the negative ones? Do they want to end with the positive items, to “end on a positive note”? Should each person go through all their notes, to avoid blocks of negativity? Each method has its benefits and each team will find their own preferred order. For teams new to agile retrospectives, the facilitator should suggest an order.
When all participants have presented their notes, the group clusters related topics. Try to avoid clusters that are too abstract like “Information” or “Process”. Instead, try to phrase a problem (or success) statement.
Prioritizing
Do a Dot Voting where each participant gets a number of “dots” (votes) they can place on an cluster or a single note. Depending on the questions, some questions might not eligible to be voted on, because they don’t produce “actionable” insight. Each participant should get a number of votes that’s about a quarter of the available options. At the end of the voting process, you’ll see which topics are the most important ones for the participants.
The voting should be quick and silent, to avoid faction-building or “agendas”. When using an online tool, use anonymous voting.
Discussion
Discuss each topic, in the order of importance. The goal of the discussion of each topic should be to find an “action item” – specific things to do to improve the situation. Sometimes the underlying cause of an issue is not clear, so the discussion might also be around what the problem is and why it occurs. For more complex topics it might be beneficial to find the “root cause”, e.g. by applying the “Five whys” technique, but keep in mind that sometimes it’s better to treat the symptoms or realize that there is no single cause. You might also dissolve clusters if it turns out that you have clustered different issues together.
When coming up with action items, make sure that they are “actionable” - specific steps with measurable results (did X improve, did Y occur less frequently, do we think Z is still a problem, etc), a due date and a person that’s responsible to carry them out. See SMART criteria. Following the SMART criteria increases the likelihood that someone will take action and achieve tangible results.
Most retrospectives should take one hour, with the discussion part taking 20-30 minutes. The moderator should remind the participants of the time constraints if a discussion takes too long and propose an action item like holding a separate workshop or meeting to investigate the issue.
Due to the time constraints, the team might not discuss some of the items with a lower priority. This is OK - if the underlying issues persist, the topics will come up in future retrospectives and get a higher priority. The facilitator may also stop discussions that need more in-depth communication and strategizing and move them to a separate meeting.
Reflection
It’s helpful to look at action items as “experiments”, small changes to processes or single actions. In the reflection phase the participants look at the action items from the last retrospective to see if the action item changed the issue for the better. If an action item is not done yet, reflect if it’s SMART enough, if there are better alternatives, if the issue is still relevant, and if the appointed person is still willing and/or able to do it. The participants can amend and drop past action items as needed.
In regular intervals (e.g. every 4 retrospectives), one participant should also prepare an in-depth look at past retrospectives for common themes and patterns:
- Are some topics recurring? Then the team might need to look for deeper issues or causes. Or it might do the opposite - if a topic is recurring, then it might also be too broad (e.g. “Knowledge Silos” or “Team Communication”) and the team could benefit from narrowing down to a more specific topic.
- How long does it take to actually “do” an action item? What could be the reason why some action items get done faster than others?
- How many topics did not fit into the discussion? Did they re-emerge? Does the team regularly drop topics?
Some software solutions, e.g. TeamRetro put the reflection phase at the end of the retrospective. I personally prefer to have the reflection phase at the beginning of the retrospective, before or as part of the brainstorming, because the “unfinished business” can give input for the brainstorming phase.
The main concepts of Non-Violent Communication
In this section, I’ll introduce the main concepts of Non-Violent Communication (NVC) in a general explanation and then give practical advice to the facilitators and participants of agile retrospectives on how to apply the concept to the different phases of the meeting.
For me, Non-Violent Communication (NVC) is primarily a specific way of thinking and perceiving what motivates people, how conflicts arise, how to solve those conflicts and how to be more honest and connected with myself and other people. It’s not about “talking friendly” or in a specific way.
Nonviolent Communication means being aware of four key concepts:
- Observations
- Feelings
- Needs
- Requests.
In the context of NVC, those concepts have a specific meaning. In the following sections, we’ll have a look at these concepts by looking at them in the context of an agile retrospective. I’ll present each one as a key distinction, contrasting it to an opposite concept.
The examples assume psychological safety - a friendly, open and honest environment where people want to collaborate on the issues presented. At the same time, I’m convinced that even if the environment is not that collaborative, the concepts of NVC might be helpful to transform it. Or at least benefit yourself and your inner monologue.
Observation
One of the key distinctions of Non-Violent Communication is between observations and judgements. Imagine a brainstorming or reflection phase that’s full of blame and judgements:
- The project didn’t finish because Paula did not do enough
- Programming language X is crap
- I could not do $actionItem because my boss assigned me too many meetings
- We never use $shinyTechnology
- The product owner is always changing their mind
Compare the judgemental sentences with more observational ones:
- I had three open pull requests that were not reviewed for three days
- Implementing a typical scenario of Y needs 20 lines of boilerplate code in programming language X, which annoys me because I know other programming languages can solve it in 3 lines
- I would like have at most 3 hours of meetings per week.
- We have not introduced a new technology in the last quarter
- We have iterated on four of the last features at least two times. I wonder if we can be more effective
You can see that the sentences are more precise, mentioning observable quantities. You can also see that most of them focus on the person, as in “I would …”, “I had …”, making them “I-messages”.
For facilitators
The phrasing of the retrospective questions matters, because some questions invite judgement and some questions inspire creativity and observation:
- Try to replace the question “What didn’t go so well?” with “What would I like to improve?”
- I also like the framing with “Anchors” and “Engines”, because it often results in the participants coming up with feelings and needs (see next sections).
One good rule to express to the participants is to avoid referring to (or even blaming) other people, inviting to use “I-messages”.
For participants
- Avoid generalizations (“always”, “never”, “often”, “only”, etc.)
- Avoid unspecific comparisons (“too fast/slow”, “too many/few”, etc.). Use specific measurements instead.
- Use I-messages, avoid naming other people
- Avoid analyzing why someone (or yourself) did something and focus on what happened.
Feelings
The next key distinction of Nonviolent Communication is between feelings and thoughts. Thoughts might look like feelings if they begin with “I feel …”, but if the words that follow the phrase “I feel …” have a “subject and perpetrator”, then they convey more thought than feeling:
- I feel left out
- I feel misunderstood
- I feel underappreciated
If other people can dispute a statement that looks like a feeling (“But I’m including you”, “I understood what you said”), then there is a high chance that it’s a thought. Genuine feelings like “I feel sad”, “I feel lonely” are hard to dispute.
Expressing your feelings in a workplace environment can feel risky, because it makes you vulnerable. And in the tech world, it’s still not common to talk about feelings and some people might even judge it as “unprofessional”. But that doesn’t mean you don’t have feelings, only that you might be not comfortable expressing them at the workplace.
Even if you don’t feel safe enough to express your feelings in the workplace, Nonviolent Communication is still useful, because you can examine your feelings:
- Naming them will help you to get a better understanding of yourself and a better connection to yourself.
- Distinguishing between feelings and thoughts, will help you to avoid conflicts.
- Feelings are connected to needs (see next section): Pleasant feelings hint at fulfilled needs, unpleasant feelings can point to unfulfilled needs.
Let’s look at the examples from the “Observation” section, adding some feelings:
- I had three open pull requests that were not reviewed for three days. I felt a bit lonely.
- I know other programming languages can solve a problem in 3 lines of code instead of 20. It’s frustrating.
- I would like have at most 3 hours of meetings per week. I feel totally exhausted and unproductive after a several meetings in a row.
- We have not introduced a new technology in the last quarter. I’m afraid I miss out important developments.
- We have iterated on four of the last features at least two times. I’m puzzled why and curious to understand our processes better.
For facilitators
- Encourage participants to share feelings, but don’t pressure anyone to share feelings (see section “Requests").
- Lead by example by expressing your own feelings.
- When people express “thought-feelings”, try to paraphrase them with different words, as a question. If you’re not prescribing feelings but asking in form of a question it doesn’t matter if you can guess the “right” words or not.
For participants
In the collection phase, while writing down your sentences, ask yourself, how you felt in the situation you’re describing. Have look at a list of feelings, to get an idea of what you might feel.
Trust your gut feelings when voting, to see which issues you feel strongly about. The voting process also shows the distinction between thoughts and feelings: You will get a better and more honest outcome if everyone votes on topics they feel strongly about and not voting “tactically” where you assume others will vote too or even to support someone’s agenda.
Improve Collection and Discussion phase by expressing your feelings (with examples).
When coming up with action items, check if you’re willing to volunteer for carrying out the action. If you have uncomfortable feelings (e.g. if you feel hesitant, resistant, “disappointed”, sad, angry or doubtful), this can be an indicator that the action item does not fulfill all your needs (see next section).
Needs
Needs are the central element of Nonviolent Communication. The key distinction for needs is between needs and strategies. In Nonviolent Communication needs are abstract and sometimes even thought of as universal to every human being. Strategies are the things that fulfill needs. For most needs there is more than one strategy to fulfill it, although most people have a preferred strategy. For example you can fulfill your need for learning and growth through online courses, books, talking to expert and colleagues, etc. You can fulfill your need for an comfortable temperature through clothing, opening the windows, getting a fan, moving around to get warm or changing the AC settings. From the temperature example you can see that conflict arise over strategies (e.g. someone opening the window or turning the heating on), while people can agree on a common shared need (for a comfortable temperature).
If you want to check if something is more of a need or more of a strategy, check if it involves a specific action, item, time, place or person. If that’s the case, then it’s probably not a need in the definition of Nonviolent Communication. There are many word-lists with needs on the internet (search for “NVC list of needs”). You can look for those lists to get an idea what other people consider abstract needs in the definition of NVC. What you shouldn’t do is use those list as a prescriptive tool to judge other people’s language, judging “this is nonviolent and this is not”. Using the lists in this way will turn Nonviolent Communication principles from a helpful tool for getting connected to other people into a source of conflict.
Similar to the “I feel …” prefix, the “I need …” prefix can also introduce a strategy. Especially the prefix “I need you to …” is rarely expressing a need and is often a suggestion for a strategy.
For facilitators
When preparing for a retrospective, think of the different roles in a team: product owner, developer, UX person, architect, etc). Each role can have “recurring” needs that come from their tasks and interactions with other roles. Try to put yourself in the shoes of each role and come up with a “top 5” list of needs a person with that role might have. Talk to people in that role and check your assumptions.
Looking at grouped brainstorming notes, check with the participants what needs are behind the points expressed in the notes. You might find different needs behind similar notes. This can help “disentangling” notes that participants grouped together, but don’t belong into the same group (or help later when finding a strategy that fulfills all the needs).
Having only one word that represents a need as a group name for similar brainstorming notes (e.g. “Efficiency”, “Structure” or “Harmony”) might not be descriptive enough. Don’t try too hard to force everything into a “Nonviolent Communication Structure”, but use NVC as a tool to find needs that might be implicated, but not spoken out loud.
Watch out for conflicts over strategies and try to find common ground after collecting each participants needs, explaining the difference between needs and strategies.
When you can’t find a strategy that fulfills everyone’s needs, sometimes the solution is “temporal” - find several strategies, then negotiating in which order you will do them. This requires some trust in the group, that everyone’s needs matter and will be fulfilled in the end.
For participants
If you feel in the mood to exercise your “NVC mindset”, bring a word-list of needs to the retro and go through the list for each topic on the board, writing down what fulfilled or unfulfilled needs might be behind that topic.
When grouping similar notes, check with other participants what the (un)fulfilled needs are.
If you’re unsure about a topic or why someone makes a suggestion, try asking about the underlying need, offering a suggestion (“Do you want to do X because you need more Y?"). It doesn’t matter if you guessed right or not, offering needs in the form of a question often has the effect of helping the other person to express their need.
When you come up with action items, it’s helpful to keep the distinction between strategies and needs in mind: The needs are the reason why you and your colleagues want an action item. The action item should represent the who, when, where and what, the strategy that hopefully will fulfill the need. The SMART criteria for action items go well with the questions for strategies: Specific (what), Measurable (what/how/where), Assignable (who), Relevant (why) and Time-Bound (when).
Requests
Nonviolent Communication distinguishes between requests and demands, by looking at the question “Can you say ‘no’ to the request”? If saying “no” has repercussions (getting punished, missing out on rewards), then a request becomes a demand. Saying “no” to a request means that you have needs that would be left unfulfilled by the request. It’s not the end of the conversation or negotiation, it’s the beginning. Although it can seem trite and manipulative, sometimes the question “What do you need to say ‘yes’?” can help to reveal the unfulfilled needs.
Most requests are suggestions for a strategy, but sometimes it’s enough to be heard and seen. A request can be a “connection request”, asking the other person for feedback on what you said, or trying to paraphrase what they said.
For facilitators
Don’t assign action items, ask the participants if there is a volunteer. If no one is volunteering, you can ask what’s keeping the participants from volunteering (after making clear that the action items are voluntary).
Pay attention to action items that don’t get done over the course of more than two or three retrospectives. It’s a sign that there are more pressing needs keeping the volunteer from doing it. Discuss during the review phase if the action item is still relevant and important to all participants.
For participants
When preparing or discussing your notes, ask yourself if you need an action item to fulfill the needs behind the note, or if it’s enough for you to be understood and appreciated by your colleagues.
When discussing action items, ask yourself what’s keeping you from saying an enthusiastic “yes” to an item that is up for volunteering.
Conclusion
The Non-Violent Communication mindset focuses on observation without judgement, recognizing feelings and a distinction between abstract needs and strategies to fulfill those needs. I think this mindset complements agile retrospectives, where the main goals are to find better strategies for working together, to (re-)connect with your colleagues and resolve conflicts in a constructive manner. On a personal level it can help you to be more mindful and engaged in retrospective meetings (paying attention to needs and feelings), and to develop more empathy for yourself and your needs inside the team and the organization.
To me, “Continuous Improvement” sometimes reeks of hyper-capitalist, competitive self-optimization and -exploitation. With an NVC mindset, it can mean “Fulfilling the needs of all participants better”.