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

• http://www.retrospectives.com -- Norm Kerth's site. Kerth is the granddaddy of retrospectives.
• Agile Retrospectives: Making Good Teams Great by Derby and Larsen -- numerous techniques for generating useful results from retrospectives. Also see their blog. They suggest this sequence: setting the stage, gathering data, generating insights, deciding what to do, closing the retrospective.
• Collaboration Explained: Facilitation Skills for Software Project Leaders by Jean Tabaka -- perspectives, approaches, and practices for effective team facilitation.
• The Art of Focused Conversation by Stanfield (editor).
• A useful set of patterns (or proto-patterns) for retrospectives is posted on the XP123 site.

The Skipper & First Mate: A Pattern for Continual Progress

How might a manager orchestrate the activities of developers such that progress is always being made? Software projects are fraught with interruptions, shifting priorities, and unforeseeable personnel events. Forward progress is often thwarted -- frequently in parts of a project, sometimes across whole projects -- when a developer in a critical chain becomes unavailable. Having a wizard developer is a wonderful thing; being in a situation where personal circumstances can lead to flow getting blocked is problematic, perhaps dangerous. In the spirit of Christopher Alexander, some observations of software development for over 20+ years are characterized here as the Skipper and First Mate pattern. It shifts attention to the feature being made and away from the people doing it.

Developing software is an exceptionally demanding intellectual task, one requiring exquisite attention to detail, crafting of architectures, inventing algorithms, and writing primo code (including effective tests). Whenever an individual developer is out of the workflow, a group's software development capability and capacity become yet more constrained. Each developer is unique. The knowledge and skills of each individual matters. The learning curve for taking on any new feature in mid-flight is daunting. The context switching is burdensome. And worst of all, some other important work would have to be shelved to free up someone who will have to drop what's underway and step in to pick up the task. Developers are not fungible, especially not in real time. The astute manager asks how such circumstances can be attenuated such that the work gets done and the critical chain remains unblocked. If addressed early, problematic situations won't spread too far or interrupt other work.

Sadly, management practice regarding software development is often blinded by an industrial-era mindset of now obsolete mass-production premises. Today, workers are no longer fungible. Developers aren't working to tend the machine as parts move through it; quite in contrast, the are creating "the machine" -- a very different thing altogether. Most of today's software managers are working in an environment where the technology, and the marketplace, are continually changing. Time is always of the essence -- every technology has a half-life, as does every market opportunity. Continual forward progress is a necessity of economic survival, a prerequisite of success. Having things delayed often means having things dropped, and the underlying investment becomes squandered. This starkly disappointing example of muda in product development is commonplace.

The cascade of illusion spawned by the mass production mindset is insidious and counter-productive when it comes to creating software. It is insidious in that it leads managers to break down work into "one person" tasks, often reflecting the tacit presumption that employees are fungible, and also separates key related elements (e.g., design and programming) into separate divisions of labor. It is counter-productive in that it doesn't recognize the risks and costs to the organization of reliance on individuals at critical chain nodes and the presumption that nothing will go wrong, and if it does, there's someone else at the ready to step in and get things done. If only it were that simple, but experience teaches us otherwise.

To the mass production mindset, the machine is the focus of human activity -- and humans are pretty much interchangeable in their roles. One person can do one job because should someone falter, another can step in a pick up where the other left off, nearly immediately. The critical chain is the machine, not the worker who is expected to execute known and often repetitive activities in a prescribed manner. With software, the critical chain goes through the human mind as the key factor in production. And that makes all the difference in the cosmos.

Things always go wrong -- people get sick, family members require attention, employees depart for greener pastures, and so on. An organization can only depend on individuals in critical chain processes when individuals are fungible -- one can quickly take over for another with no interruption of the work flow. Moreover, it implies that there's a pool of available developers, ready to step in, who themselves aren't engaged in other priority activities. Software isn't like that. Often, losing a developer, even for a while, means a feature or fix just got delayed or perhaps dropped. To the bean counters, and hopefully the managers, this means the entire investment has just been diluted, if not squandered. When such circumstances occur, expectations need to be reset -- uncomfortable conversations follow that never turn out well. This happens every day in organizations everywhere. There is an easy solution to this dilemma.

Many software managers practice, or have accepted the pressure, to assign single tasks to single individuals, and they leave it at that. Workplace rhetoric echoes with "directly responsible individuals" or of the importance that every task must have an "owner" if there's to be any hope of getting something done. Single individuals, of course, can complete even the most complex software tasks, but is that the best way for manager to ensure the feature gets done? Creating a feature, for instance, has diverse aspects (e.g., designing, coding, testing, etc.) any of which could be further decomposed into absurd detail. In the mass production mindset with its proliferation of organizational roles in the division of labor, it wouldn't be surprising to see each of these aspects handled by a different person in a different department. Role proliferation induces complex work flows, balkanizes knowledge, and creates numerous wait states and boundary transitions: all muda.

Accountability, of course, is a Wonderful Thing. But accountability doesn't go far enough when delivering a feature is the point of the activity . Having "one person responsible" shouldn't imply, as often seems to be the case, that only one individual gets to contribute to, and have responsibility for, getting something done. From a managerial standpoint, this raises a provocative question -- which is more important: having someone to blame or ensuring that the task gets done? To observe most organizations and most managers is to see that blame often trumps progress. Otherwise, managers would staff their projects to first and foremost ensure task completion. Too much conversation about responsibility drives out conversation about work and thereby diminishes the signal-noise level related to effective progress. A sticky web of human relations, violated expectations, and politics follows all of which detract from the objective of completing the work as originally intended.

The solution is actually simple: ensure that at least two people sign up for any feature (in a ranked manner described below). While two people share the tasks one is primarily responsible (a "skipper" so to speak) -- should things go awry, it becomes the other person's responsibility (the "first mate") to ensure the tasks get done. The focus here is on the completion of the feature. The pairing creates a circumstance of ensuring that knowledge is shared and that the work gets done. From a deployment standpoint, this means that at any one time, more people are assigned to fewer features, but those fewer features typically get done faster, with each avoiding the risk of total disruption due to factors arising from an individual's unforeseeable circumstances.

Yes, this means pairing, although not necessarily XP's keen insight of pair-programming. Just "pairing". It is an effective mechanism for enhancing team performance. In the simplest sense, pairing means two people working together -- not reflective of a pas-de-deux or duet, but more akin to a master-journeyman relationship or perhaps a bicinium. It means two people are responsible, one more so than the other, for finishing the work. Staff deployment for an iteration then has both a skipper and a first mate for each feature, aspect, or task being undertaken. With software teams, the skipper on one task also serves as the first mate on another, and vice versa. Given that every iteration has a prioritized activity list to be undertaken by the team (typically longer than can reasonably be completed) developers are deployed as skippers for the highest priority backlog items. Everyone is expected do serve in both roles.

Organizationally, the Skipper and First Mate is a powerfully productive pattern -- features get done at a reliable pace, personal circumstances of individuals don't thwart progress by disrupting a critical chain, and tacit knowledge diffuses throughout the team. The work gets done; progress continues apace.

Cooperation between the skipper and first mate takes many forms -- if the skipper is writing a feature, the first mate can be writing appropriate tests. If the skipper is authoring a design document, the first mate is available in a most timely manner for reading it closely for coherency and accuracy. If the skipper gets the flu, must return to the other side of Planet Earth, or is reorganized out of the workgroup, the first mate is obliged to step in and move the task forward until next iteration. The skipper and first mate allocations are revisited at every iteration planning session. This is a pattern of organizational adaptation to the changing circumstances inherent in having individual developers in a critical chain.

For every feature, developers are brought into on-going conversations with someone else about the design and code. They get a quick response for reviews, and get testing support right away. As a result of the interactions, more insights are generated, more risks are identified, and more solutions are surfaced. The key point here, however, is the feature typically gets done sooner than if an individual had done it alone, but more fundamentally, it's much more likely the feature will get done as a matter of pace in circumstances where the "directly responsible individual" becomes unavailable, distracted or reassigned. The critical chain is not disrupted and positive results are achieved.

The Skipper and First Mate is a pattern reflecting cooperation and readiness; it's about a shared objective and commitment. Someone with appropriate knowledge and skills is at the ready, but not waiting in reserve. No one sits idle, but the impact of any single individual's personal circumstances whether it be family emergency, temporary mind-block, whatever, doesn't thwart progress. The work gets done. In an environment of peer reviews, this pattern brings a shared sense of accomplishment, and respect for each other's contributions. The Organization benefits.

When bringing pairing to a team, the manager is faced with the delicate, but all so real, factor of personalities. Pairing is not a comfortable habitat for lone wolves. The extent that a manager caters to them (consciously or otherwise) does shape the nature of the team's activity and subsequent team performance. Inherent in this is the risk of diluting or squandering the to-date investment, and not meeting stakeholders' expectations.A manager needs to determine whether the work at hand requires a team or can be done by a set of individuals in critical chains. In a research group, for example, critical chains are few; in a product group they are common. Often, reliance on lone wolves brings about circumstances of critical chain disruption (and all the subsequent muda of adaptation and corrective action), although not necessarily intentionally. In an environment of peer reviews, this pattern brings the piercing eye of scrutiny. The Organization learns.

This pattern is offered in the spirit of Alexander's A Pattern Language, especially as brought to software engineering management through Coplien and Harrison's Organizational Patterns of Agile Software Development. Following the pattern definition of hillside.net, we have:

Name: Skipper and First Mate

Problem: An individual in the critical chain for completing a feature may at times becomes unavailable. The feature is necessary for an upcoming release and other teams are depending on it being ready for their own commitments. It is vital that the organization / department / team deliver the work in a timely manner.

Forces: Social pressure, economic understanding, and development habits lead managers to deploy staff in an ineffective manner. The work is on a critical chain for a project or feature needs to get done or is perhaps needed for an upcoming release or other teams are depending on it. Managers who have many responsibilities often believe that unless they assign one person per task they're not being efficient and this will reflect badly on them. These manager succumb to the mass production mindset of assigning one person per task. Problems can occur and the individual on the critical chain becomes unable to deliver in a timely manner. The work on the critical chain falters. Should the manager have placed two people on the task and the roles and expectations are unclear, efficiency is reduced as one person can remain idle and the situation of too much undone work becomes worse and the circumstances repeat themselves.

Solution: Sign-up two individuals, the "skipper" and the "first mate", with a clear order of responsibility and expectations of collaboration such as the skipper writing a feature while the first mate writes tests, the skipper writes a design doc whilst the first mate is at the ready to review it and so on. Should the skipper become unavailable; the first mate steps in to ensure the work is completed.

Resulting Context: The developer team becomes accustomed to working in pairs that are dynamic and often shift iteration by iteration. However, in organizations where the culture emphasizes single individual responsibility and individual accountability is more important than forward progress, a manager may be viewed negatively for implementing such a pattern leading the manager to return a single-task-per-person approach, thus reintroducing critical chain risks of reliance on single individuals and the cycle begins anew.

Rationale: Avoid depending on a single individual on a critical chain for development that is time critical.

Developers are bright folks. Many quickly recognize the personal advantages afforded by this pattern once they experience it. The skipper has someone to draw on, and the savvy ones will find advantage in that, especially for quick design, code reviews (or at least perusals), and testing. The first mate likewise knows that lending a helping had averts getting saddled with the work, and getting recognition for the contributions. Both recognize that influence of peer reviews on performance ratings. And the manager recognizes whether the feature got done. The organization continues progress apace.

The Skipper and First Mate pattern is broadly applicable. I've seen it work from advanced software development teams to university research projects, from the profit-focused corporations to non-profit service organizations. Most of all, people like to get things done, and many people like to work with others. This pattern is a simply way reducing risks along critical chains, ensuring necessary work gets done, and providing a convenient and comfortable opportunity for people to work together.

For more information on patterns, visit: c2.com, The Gang of Four, search Google books, or see pattern-related Amazon listings.