I recently sat through a software development team retrospective. The facilitator began the retro by taking the “temperature” of the room.
He asked us to write on a card how comfortable we were with this environment and how likely we were to speak up. Partly because of my newness on the team, and partly because I wanted to see what would happen, I wrote down a ‘1 — unlikely to participate’ on my card.
The results were collected and tallied. My ‘1’ showed up as an outlier, the rest of the responses were a ‘3’ or higher (out of 5.) The consensus was that we were fine. We plowed into a fairly standard “Good Things / Bad Things“ retrospective.
And I stayed silent.
Playing the introvert is hard for me. I almost always have an opinion. But ignoring my response left me feeling unsafe and less likely to speak up.
Don’t get me wrong, the facilitator was well-intentioned, and I appreciated the ‘temperature check.’ But while identifying potential problems in the team, it did little to address them. I felt disconnected from the team and I left the retrospective pretty discouraged.
How about you? How do you feel after your team retrospectives? Are you discouraged and pessimistic about all the problems that your team has? Do you feel more or less connected with the rest of you team? Do you leave frustrated by what people are or aren’t doing?
I think retrospectives ought to bring teams together. Participants should leave them feeling optimistic about their strengths and excited about the things that they will do to build on those strengths.
I’ve developed a retrospective process that will do this. The truth is, I’ve stolen most of these ideas from my wife. She is a career church worker and was introduced to the concept of Appreciative Inquiry in a class on ministry assessment. She passed along her textbook [1] and what follows is mostly an adaption of the ideas in that book. I'd like to take you step-by-step though facilitating an Appreciative Inquiry retrospective for a software development team.
Inquire
Start by asking questions. If you look closely you’ll see that the questions that follow are all appreciative in nature. There are no questions like “What is our biggest problem?”
I understand if you are skeptical about this. Isn’t the point of retrospectives to talk about problems? Don’t worry, the problems that the team has will come out in this process. The difference is that the attitude and tone will be much different. If it still seems counter-intuitive, just trust me for now.
For each question, ask participants to first write their responses on index cards. This helps to level the playing field between introverts and extroverts in the group. Many great ideas will come from quieter people whose voices otherwise might not be heard.
Ask each question, and give participants time to write their responses. Then ask people one at a time to share their response. As each person shares what is on their index card, have them toss it out into the middle of the table.
Warm up question
Your first question gets the participants’ appreciative juices flowing. Ask them to recall their best experiences on the team.
Reflecting on your entire experience on this project, remember a time when you felt the most engaged, alive, productive, and motivated. What did you do? How did it feel? What happened? (Adapted from Branson 68)
Value Questions
Your second set of questions focus on values. You should tailor the questions towards the values of your particular organization or group. Here I’ve written four example questions based on the four values in the Software Craftsmanship Manifesto. These questions are targeted at a group of developers. I have another set of value questions that I ask when the retrospective is done together with a client.
Notice how each question asks participants for the “healthiest, most beneficial aspects” or “the best parts” or “the most valuable thing.” These kind of questions are the distinguishing characteristic of Appreciative Inquiry.
What are the best parts of the system we’ve been building? What is the most well crafted area of the code? What characterizes that code?
What are the healthiest, most beneficial aspects of our partnership with our customer? What would you say is most important about how we relate to each other? Give some examples of how we work together at our best.
What is the most valuable thing we have delivered in the project? What benefits has our client seen? Tell me about when we have had a great streak of continuous value delivered.
What are the healthiest, most beneficial aspects of our relationship with each other? When we are at our best, how do we contribute to our team and the larger development community?
Personal Values
Next, ask participants to talk about their individual contribution. This is a way for people to identify their own strengths. It feels a little bit awkward to talk about yourself in this way. Self-deprecation is much more comfortable for most people. As hard as it may be, identifying individual strengths is crucial to Appreciative Inquiry.
Don’t be humble; this is important information: What are the most valuable ways you contribute to our team personally — your personality, your perspectives, your skills, your activities, your character? Give me some examples. (Adapted from Branson 68)
Team Values
Now ask a similar question, except ask it about the team as a whole.
What do you think is the most important characteristic of our team? When we are at our best, what is the single most important value that makes our team unique? (Adapted from Branson 68)
Wishes
This final question is perhaps my favorite of all. This is where your team’s problems will certainly emerge. You’ll be amazed, though, at how much more productive the conversation will be when problems are expressed as wishes. When you talk about your wishes, you've already moved passed complaining about the problem; you've begun to solve it.
Make three wishes for the future of our team. Describe what the team will look like as these wishes come true. (Adapted from Branson 69)
Imagine
Next (and perhaps after a short break), ask the team to take the responses from the inquire step (now strewn about the table) and group them together. As you slide cards around on the table, themes will start to emerge. For each group, write a new card that expresses this theme and place it on top of that stack.
Now, for each theme, ask the group to generate a provocative proposal. Branson (152) explains that Provocative Proposals:
- …are stated in the affirmative, as if already happening.
- …point to real desired possibilities.
- …create new relationships and partnerships.
- …bridge the best of “what is” toward “what might be.”
- …stretch the status quo by pushing boundaries.
- …necessitate new learning.
- …challenge organizational assumptions and routines.
Don’t be afraid to let the group be ‘unrealistic’. Try to ignore real or perceived barriers to change and see what people can come up with when constraints aren't imposed upon them.
Provocative Proposal Example—Continuous Deployment
When I check into the git repo, all of the code is built and the tests run. After a successful run, the code is automatically deployed into the staging environment. Later, I push a button and the code in the staging environment is deployed into production.
Write down the proposals as they are generated. Use large index cards or a computer with a projector. In a larger group, you may need to divide up the themes and have smaller groups work on proposals.
Innovate
Finally, help the team break down each of the provocative proposals and figure out how to make them a reality. As a group, generate tasks and let team members commit to action. You’ll likely have to economize here and pick the top provocative proposals. The thickness of the stack of cards under the proposal is a good way to determine where to start.
Tasks should be specific, measurable, and have deadlines attached. Record the tasks and commitments in a visible place so that the team will often be reminded of the things they have decided to undertake.
- Enhance the test runner with better failure identification—Paul by next Friday
- Write a deployment script—Jim by next Friday
- Figure out hooks in CI server and hook in new script—Doug by next Wednesday
- Write a script to deploy from staging into production—Jim by next iteration meeting
Innovation Example—Continuous Deployment
Conclusion
The stresses of day-to-day project work can strain relationships on your team. If you hold retrospectives that just ask team members to identify problems and come up with solutions, you may be avoiding some underlying tensions. A problem-focused retrospective can quickly turn bad, leaving the participants tired, discouraged, and hopeless in the face of mountains of problems.
In appreciative inquiry, however, your process is as valuable as your results. Building up a list of things that your team appreciates about one another can restore deteriorating relationships and set the team back on a productive, encouraged, and hopeful path.
Branson, Mark Lau. Memories, Hopes, and Conversations - Appreciative Inquiry and Congregational Change. Herndon, Virginia: The Alban Institute, 2004.