3.29.2008

Retrospectives: Informed, Continuous Team Improvement

A retrospective, in simplest terms, is a facilitated, focused dialog. It is a time-tested and valuable method for improvement. Retrospectives draw immediate attention to ineffective situations and problematic circumstances. While related to notions like an "after action review" or a "postmortem", a retrospective explicitly examines current circumstances and looks to the future with an eye towards becoming better. Retrospectives are becoming ever more common as teams follow lean principles and agile practices to improve their performance as effective software development organizations.

Learning is key in the pursuit of excellence. Retrospectives reflect the human desire of attaining perfection, yet the recognition that it escapes our reach; hence, only by continually improving can we get closer. While retrospectives are useful in many types of situations, this essay is focused on the utility of retrospectives for improving team performance within on-going projects.

Retrospectives are learning situations. No matter how capable a set of developers may be as individuals, their overall productivity is constrained by the flow of their work. The timing and structure of their activities can either add lift or induce drag on that flow. Add to that the complexity of working together in teams, in a company awash with bureaucracy and politics, and it's a wonder that they can deliver any software at all. Yet we do. But, can we do better? Retrospectives are all about improving team performance and adding lift in that regard.

Retrospectives are situations where key issues are surfaced. They provide an opportunity for a team to take stock of their circumstances, assess the forces at work that influence them, and engage in focused brainstorming as to what to do next. It's a time to step back and look at the work and the flow. Typically, a retrospective identifies what's going well and what could be going better. With the overall situation out on the table, the team can identify one thing (one is enough) to improve that could make life a bit easier.

A retrospective doesn't seek to "fix something" and the totality that implies. The point isn't to come up with lofty visions, missions, or elaborate, phased implementation plans; it's not an intervention, and certainly not a silver bullet. Quite in contrast, a retrospective calls on people to see where they can simply "lighten the load" by improving their situation in one small way immediately. Retrospectives avoid blame-games and embarrassments, and because they happen frequently, problematic factors are brought to everyone's attention so problems can be addressed early on. The emphasis is not on "what went wrong", or who "did wrong", nor even "what when right" but, more importantly when improvement is the goal, "what to do better next time." With the cumulative nature of retrospectives, the benefits add up.

Is the code so jumbled that people wish for the good old days of spaghetti? Are vague requirements problematic? Are other parts of the organization creating a false sense of urgency for their own purposes, or behaving as if they are trying to "drive" the developers? Have deadlines upon deadlines and interruptions that interrupt interruptions sucked away all oxygen? Are there too many meetings? Is everything the #1 priority? Is the team limited by too few developers with relevant skills for the project? Are the tools broken? Is Mr X's lack of tests on Bar the reason that Ms Y's Foo code submission had to be rolled back? Is the geographic distribution of the team causing overhead and confusion? Are sloppy code and poor testing prevalent? Are there components that desperately need to be refactored? Are people mistaking haste for speed and creating a situation there never time to "do it right" but always time to "do it over"? Over time, the list of what's broken or needs improvement can get daunting. But through retrospectives, those circumstances that can be changed can be identified, and the most important ones can be taken on one at a time. Continuous improvement follows. Success builds.

A useful practice with retrospectives is to identify one single thing to improve (for now). This is for two reasons. First, if the team can't improve one thing they certainly can't make better two or more. Second, retrospectives are typically recurring events; after a while, fixing "one per" adds up. When a team is practicing iterations, say with 2 week intervals, that's a dozen or so things/circumstances the team consciously improves over this Quarter and next. Although the practice of retrospectives isn't necessarily tied to the practice of iterations, the two amplify each other in a virtuous circle.

So, the suggestion here is for every team to adopt the practice of retrospectives. Use them to identify circumstances that can be improved. If code reviews are a bottleneck, does there need to be a quick focus on having additional developers become skilled in a component and become a component owner? If yes, buddy up, see to it. Are necessary tests being put off? Discuss pairing up -- have one developer write a component while a teammate writes the tests for it; then switch. Code and tests will get written, knowledge will be distributed, and more things will actually "get done" quicker. Are there too many outside interruptions? Discuss a way to quickly triage them and, except for those truly urgent, schedule recurring "office hours" to handle them then, and so forth.

Retrospective Guidelines. Each retrospective is unique and the specifics must be tailored to fit the situation at hand. Nonetheless, practice in accord to some guiding principles is beneficial. Here are several suggestions, ranked in order of importance.
  1. Facilitator. Trying to hold a retrospective without a facilitator is simply a waste of time. Make sure that every retrospective is facilitated by someone who manages the floor, moderates the conversation such that everyone gets to speak, and that no individual dominates. The facilitator is obligated to not comment, critique, or otherwise influence the content of the conversation. The job is to manage the flow. Stick to the question. Don't drift. Don't rush.

  2. Neutral open-ended questions. Probes such as "what's going well" and "what could be going better" effectively reveal current circumstances and point to activities and situations to either foster or curtail. Avoid leading questions or questions that imply particular answers. More on questions below.

  3. Scribe visible notes. For the facilitator, use the white board. Designate a scribe to take notes (the facilitator is too busy). When video conferencing, the scribe can display in presentation mode so the distributed participants see the notes as they grow. Archive notes in a persistent location for rapid search and retrieval.

  4. Identify an improvement to put into practice. While the group is together, identify a single action to take that could make things better. Pick something tractable that is within the purview of the group holding the retrospective (e.g., making a commitment to refrain from checking in any code to the main trunk until tests are proven, finishing up small "niggling" things that seem to be getting in the way, establishing a continuous build process, and so on). Decide on one, put it into practice, review its effectiveness the next time around. If it works, pick an additional thing. If not, work on it until the underlying situation is alleviated.

  5. Schedule sufficient time. The author's personal experience is that iteration retrospectives require about 50 minutes at first, but then level off at about 15-20 minutes. It becomes an enjoyable time of sharing points of view and figuring out ways to improve. In contrast, for retrospectives reflecting on events or engagements or such, personal experience is that 90 minutes are needed. Hour meetings tend to be ineffective because there's too much to cover, too many tales to be told, and people too antsy to have their say. When such events repeat occasionally, say every Quarter, they level off to about 45 minutes or so after the second or third time.

  6. Repeat with a regular cadence. Decide a regular rhythm for retrospectives. They're an ideal fit for a team practicing iterative development, in that every iteration planning session can begin with a brief retrospective. In 15-20 minutes everyone gets a clear picture of how things are going and which improvement to next adopt. In this way, potentially problematic practices and circumstances are identified, called out, and action is taken to resolve them. It's also a good idea to hold a focused retrospective after all major events -- for example, a major feature release, a significant refactoring effort, a change in build methods, following an engagement with a vendor, or when interns return to school. Each of these situations has lessons to be learned.
Facilitator Guidelines. It is true that expert facilitation is a learned and disciplined art whose mastery requires years of diligent practice. Nonetheless, a few guidelines can get anyone started in the right direction. As a facilitator, be mindful of the following items and the retrospective will yield effective results.
  • Prepare the venue. Yes, as silly as it sounds, arrive prepared if you're the one to lead the show. If needed, have the VC ready and camera aimed. Have working dry-erase markers (and know the location of the nearest supply station). Have any visual aids, worksheets, estimating cards, or other work items in sufficient supply. Ensure there are enough chairs.

  • Ponder the topic questions. Give some thought to the likely interpretations and flow beforehand. Participants may be curious about preferred depth of details for responses, whether to use people's names, whether the proceedings are confidential, etc. Be ready to address such inquiries. If you are familiar with the participants, reflect on who might attempt to dominate the floor and who might need to be drawn out to comment. Anticipate.

  • Set ground rules. Call to order and ask everyone to agree to a set of ground rules. It's useful to have these written or displayed. Get agreement on the ground rules before proceeding. Some suggested ground rules: treat everyone with respect, no laptops (except for the scribe), don't interrupt whoever is speaking, take turns -- don't speak twice in succession, cell phones on stun, take calls out of the room. Make sure the scribe is taking minutes.

  • Stand, don't sit. Much of facilitation is executed through body language: proximity, pointing, and hand signals. One must be standing for these to be visible and effective. Most likely the facilitator will be writing on the white board. Be animated; keep the energy level up.

  • Control the floor and the clock. The job of the facilitator is like that of a moderator, although using prepared questions. Be vigilant regarding the agenda and mindful of the clock. Keep the conversation moving. It's rare that anyone has something that can't be said in 60 seconds or less. A minute is a long time for a thoughtful remark. Be ready to politely cut off someone who is enamored by soliloquy, and to do it as many times as necessary. Be attentive to body language such as raising of hands or fingers for a turn to speak, obvious excitement to say something, lack of attention due to staring at the mobile device. Be public. Call them on it.

  • Remain neutral. Be careful not to favor particular points of view, importance of problems, nor manner of solutions. It's important to curtail someone's enthusiasm for arguing a particular perspective; the retrospective is not the venue for that. Be careful of skilled rhetoricians who will ask the moderator leading questions such as "wouldn't you agree that" or "isn't it obvious that". The facilitator's duty is to enable the collective to reach its interpretations and decisions. It is a unique rhetorical vantage point. Stay above the situation, focus on mining the team's wisdom.
Starter Questions. Neutral questions are vital. A retrospective's purpose is to surface issues that are shared amongst the team, especially those that reflect positive practices that should be continued and negative ones that should be curtailed. It's a situation in which valuable insights arise. To go into a retrospective with a preconceived notion of what the results "should" be, is (as Mr. Boffo would say) being "unclear on the concept."

Depending on the retrospective situation, different questions are useful. The range of potential questions is boundless, and many precious hours can be whiled away striving to find "just the right ones" or some such. Don't do that. Start off using very simple ones. During the session, finish one question before moving on to the next. Capture the unique ideas, not the myriad ways that different people might be rephrasing the same notion in order to have their say. After facilitating about five or so retrospectives, the key questions will become evident given the team's capability, capacity, circumstances, and personalities. For starters, though, just pick a set below (tailored for iteration meetings) and get going.
  • Use the time-honored set of: (1) What's going well?, (2) What could be going better?, and (3) What one thing can we improve now, and how? Identify what will be changed and have everyone sign up for some part in it. Before you choose, decide -- collectively.

  • A parallel and humorous approach to this is to write three headings on a white board: "good", "bad", "ugly" and then go around the room having everyone make a remark under each heading. Pick something to improve right now, brainstorm what can be done. Have everyone acknowledge commitment to making the change.

  • The author's favorite -- after a brief reminder about drag and lift regarding flight, ask: (1) What's adding "lift"?, (2) What's adding "drag"? (3) Name one small thing we can do to reduce drag.

  • A different set: (1) What should we keep doing? (2) What should we stop doing? (3) What puzzles us? (4) What do we need to change now?

  • Yet another: (1) What did we expect to get done? (2) What is finished? (3) What caused the delta? (4) What can we do to improve it?
Retrospectives focused on events or particular circumstances can be served by questions of a different nuance. For example, if the purpose is to see what can be learned from a particular set of circumstances such as a previous project, a collaboration between two or more groups, experience with a vendor, and so on. Here are some starter questions for those retrospectives.
  • (1) Name a headline that best captures the experience. (2) Name a negative (but true) headline that reflects the worst of the situation. (3) What do you wish you knew then that you know now? Following that, identify what to do differently next time.

  • (1) Describe the situation with a cliche. (2) What practice or approach that was done do we need to remember to do again? (3) Say you had a "magic wand" and could have changed any one thing, what would that be?

  • (1) What policies/procedures added lift? (2) Which ones added drag? (3) What's the lesson learned? Identify something to improve immediately.

  • (1) What worked? (2) What broke? (3) Where can we do better?
A pragmatic note. Retrospectives, lean development, agile practices and the like are for teams. Teams are about collaborative activity, working together effectively, maintaining a shared perception of the situation, and a commitment to collective success. The mere perception of all this is beyond the ken of selfish or self-centric prima donnas. They can't see it; in a manner of speaking, they're tone-deaf to the distinction between a group and a team, and the "manner of being" in a team eludes them. Don't expect these techniques to work with them. But if you're actually with a team, the practice of retrospectives delivers high value for improving working conditions, enhancing how work gets done, and having shared pride in the work: something only true team members ever experience. Please, if you think that only 20%-30% of a retrospective meeting would be useful to you -- don't attend. Rest assured; you won't be missed. For everyone else, retrospectives are a simple, quick, and powerful practice to improve the team's overall situation.

Interesting Reading

posted by Jamie Z Fox at 12:48 AM