Retrospectives


On the rim of one volcano with the cone of a second in the background!

I am hiking volcanoes this week, literally! The 400+ page copy of Thinking, Fast and Slow has not been in my day pack (it is in the luggage). We will be back next week. If you are in Portland, Oregon, I hope to see you at the Pacific NW Software Quality Conference beginning October 14th through the 16th.  I will be speaking on the 15th! Register now: https://www.pnsqc.org/2019-conference/

Also, remember that I have a webinar on value stream and process flow mapping for The Great IT Professional Organization on October 22, 11:00 AM – 12:30 PM EST. The registration link is http://bit.ly/2VaFzm3  The webinar is free!  I hope you have time to be in the audience!

Sitting on mountains this week has caused me to reflect on an entry from January 1, 2015, titled, Getting Stuff Done: Daily Retrospectives.  A re-edited version follows —

Reflection is a central tenet of all Agile frameworks. Do a bit of planning, execute against that plan, then step back and reflect on what was done and how it can be done better. Reflection acts as both a capstone for a period of work and as an input into the next cycle. For example, in Scrum, each sprint culminates with the team performing a retrospective so they can learn and improve. Retrospectives have the same power whether they are team-based or done at a personal level. In personal Scrumban, performing a daily retrospective is useful to generate focus and then tuning that focus based on the day-to-day pressures and changes in direction. (more…)

Your Scrum events might be slightly less well attended!

Your Scrum events might be slightly less well attended!

The list of identified events in the Scrum framework, like the number of roles, is highly constrained. Scrum walks the line between identifying a set of events that each follow a typical pattern and prescribing specific activities and tasks.  As a framework, Scrum leaves the control of specific behaviors to the team. Therefore each team has a customized approach to how they implement the events based on organizational culture and need. The events identified in the framework include:

  1. The Sprint: which is the time box for developing potentially implementable functionality.  The sprint generally ranges from 2 – 4 weeks, with the 2 week increment being the most common I see in the industry.  Once your team agrees on the sprint duration for a particular project, it generally does not change.  The standard duration of the sprint is called cadency. Developing a consistent cadence helps the team become predictable.
  2. Sprint Planning: a meeting for the team to plan the work they will commit to during the sprint.  Sprint planning is a two-step process beginning when the product owner identifies the units of work they want included in the sprint using the prioritized backlog and input from the team for guidance.  After the product owner identifies the work he or she wants in the sprint, the development team (I recommend that the whole team participates) estimates the work based on their velocity (how much work they typically get done in a sprint) and the activities needed to complete the work (completion must meet the teams overall definition of done). The team will either increase or decrease the number of work items based on what they can complete.  What the team WILL NEVER do is to change the definition of what done. The planning activity is complete when the team can commit to completing the work they can do during the sprint.
  3. The Daily Scrum: the daily planning session that generally begins the team’s day.  The daily meeting provides the team with a mechanism to plan the day and to ensure that issues blocking work do not fester. Try to keep the scrum meeting at or near the beginning of the day so that team can use it as tool jump start their day.  Team composition and time zone constraints will dictate when the meeting happens.
  4. The Sprint Review: the meeting at the end of a sprint for the product owner and stakeholders to interact with the functionality and provide feedback and acceptance.  The sprint review provides a platform to gather feedback from a broader constituency than the team itself. The whole core team should be interacting on a daily basis; therefore the review should be leveraged to include a wider range of stakeholders.  The product owner should drive the guest list with advice from the entire team.
  5. The Sprint Retrospective: a meeting for the team to review their performance and identify opportunities for improvement. The team should find at least one process improvement that they can make and then commit to making that change.  The change the team commits to should be captured as a unit of work and be incorporated into the next sprint backlog so that it gets done.  Process improvement is the obligation of the WHOLE team, not just the development team.

The five events identified in Scrum are sometimes explained as four meetings and the sprint, which is an intrinsic part of Agile techniques.  All five are important features that interact providing self-reinforcing discipline and feedback.  I usually worry less about how a team is accomplishing the events, rather I make sure they doing something that meets the intent of the events and are in line with the Agile values and principles.

Retrospectives look back to impact the future.

Retrospectives look back to impact the future.

In the Daily Process Thought, August 22, 2013 we discussed list-generation retrospective techniques.  They are easy to execute and have a great track record.  However, there are other, more specialized techniques like the Timeline Retrospective, which is useful for long-running releases or in projects were a retrospective has not occurred in recent memory. These techniques deal with more complex issues than can be tackled using simple lists.  These more complex methods can also be used to spice up a more basic fare of listing techniques to keep teams involved and interested in the retrospective process.

These techniques are more complex to execute.  Let’s explore a few examples of this class of retrospective.

The Timeline Retrospective uses the following process:

Goal: The Timeline Retrospective technique develops a visual overview of the events that occurred during the period under investigation.  This technique identifies and isolates the events that impacted the team’s capacity to deliver over a set period of time. It uses distinct colors to identify events (avoid typical red – green colors as color blind participants may have difficulty).

When To Use:  The Timeline Retrospective is useful for refreshing and re-grounding the memories of team.  Other circumstances in which this may be a useful technique:

  • If there have not been any intermediate retrospectives;
  • To provide context to program-level (i.e. multiple projects) retrospectives;
  • If the team has not been working on the project over the whole life cycle, and
  • An end of project retrospective.

Set Up: Draw a timeline that represents the period since the last retrospective on a white board (or several pieces of flipchart paper).  Make sure there is room above and below the line.  Secure dry erase markers in a few colors and sticky notes in three colors.  The three sticky note colors will represent:

  • Blue represents good events;
  • Yellow represents significant events that are neither good nor bad, and
  • Red represents problem events.

Use the colors that you feel the most comfortable with and that you have in sufficient supply.

The process is as follows:

  1. Have each team member silently write down on sticky notes the major events, from their perspective, using the color code from above.
  2. Have each team member put their events on timeline chronologically, placing positive events above the timeline, neutral on or near the timeline and negative events below the timeline
  3. Throw out duplicates.
  4. Have the team select someone to walk through the final timeline.
  5. Using the dot voting technique (provide each team member with three dots) rank the event that slowed the project down the most to date.
  6. Identify tasks and actions that could be taken to solve the problems. Pick the top two or three.
  7. Have the team tell the story of the project for the next sprint or release, if they took the identified actions. This will help validate the choice of the proposed changes.

Another example of non-list retrospectives is the 6 Thinking Hats Retrospective (based on De Bono’s Six Thinking Hats).  I use this type of approach when the team has experienced significant challenges, has not established norms on how to interact or tends to be dominated by one or two personalities.  In this technique, the team uses a structured approach to discuss the period since the last retrospective.  The team “wears” one of De Bono’s “hats” at a time, which means all participants talk about a specific topic area at a time. Each hat represents a particular way of thinking.  Using the hats forces the team to have a focused discussion (this is called collective thinking in the literature). Until you are comfortable with this type of technique, use a facilitator. The facilitator should ensure that the comments are appropriate to the “hat” that is currently being worn. Here is the order of the “hats”:

  • Blue Hat (5 minutes) – focus on discussing session objectives.
  • White Hat (10 minutes) – discuss or identify FACTS or information since the last sprint (e.g. we had a hurricane during this sprint).
  • Yellow Hat (10 minutes) – talk only about the good things that happened since the last retrospective.
  • Black Hat (10 minutes) – talk only about the bad things that happened since the last retrospective.
  • Green Hat (10 minutes) – talk only about ideas to solve the identified problems or would add more significant value in the Product Owner’s perception.
  • Red Hat (5 minutes) – Have each team member come to the white board or flip chart and write two emotive statements about the project during this period. Do this fast and with very little preparation.  You want gut reactions.

As team review the emotive statements to identify clusters of comments or trends that can be combined with the issues in green group.  From the identified issues pick one or two actions that will improve the ability of the team to deliver to add to the backlog for the next sprint.

Other techniques in this class include:

Emotional Trend Line – This is many times combined with the Timeline technique. It provides an estimate of the team’s emotional state since the last retrospective.

Complexity Retrospective – Draw a complexity radar plot with at least five axes. Engage the team to determine what each axis should be labeled (e.g. data, workflow, code, business problem) and then engage the team to rate each axis.  If an axis is rated as complex ask the team to identify actions to reduce complexity.

Non-list based retrospectives are generally more complicated to apply due to the formal structure they use to guide teams toward discovery.  For example the De Bono’s Six Thinking Hats will require active facilitation (at least until everyone is comfortable with the process).  These techniques are generally used to address special or specific circumstances.  The structure of the techniques has been designed (or in some cases these techniques were adopted from other disciplines) because they help to focus the retrospective participants on a type of problem. The goal of any retrospective, list or non-list, is to help the team to discover how they can learn to be better during the next iteration.

Daily Process Thoughts:  Retrospective Theme Entries:

Retrospectives: A Basic Process Overview

Retrospectives: Retrospectives versus a Classic Post-Mortem, Mindset Differences

Retrospectives: Obstacles

Retrospectives: Listing Techniques

Retrospectives: A Social Event

Crowd sourcing is a key retrospective technique.

Crowd sourcing is a key retrospective technique.

Even though there are many different techniques for executing retrospectives, many teams find one or two techniques they like, and then they ride that horse until it collapses.  As we noted in Retrospectives: Obstacles, every Scrum Master and team should have a broad array of retrospective techniques, such as the sailboat technique, the Four L’s or the timeline.  This provides at least two benefits. First, knowing many techniques means that you can match the technique to the particular teams. For example, many techniques use physical sticky notes, which are difficult for distributed teams. So, the Scrum Master needs to know that you can substitute an on-line mind mapping tool for sticky notes.  Second, having a wide range of techniques (and using them) is a formula for beating technique fatigue and the resulting obstacle.

List generation techniques are the most popular class of retrospective techniques.  The list generation techniques are popular because they take very little set-up, are easy to explain, easy to facilitate and get results. Listing techniques build on well understood brainstorming techniques to ensure the whole team has a voice.  Before, we described how to do a retrospective using a simple listing and grouping technique, also called Affinity Diagraming.

Another technique in the listing category would be the Sailboat technique.  This method uses a nautical metaphor.  The boat moves through the water toward a goal (the team delivering functionality), the wind pushes the boat forward.  As the boat moves through the water, it encounters resistance which slows its progress. Examples of resistance might include conflicts for needed resources or conflicting organization goals.   Here is the process:

  1. Set-up: Start by drawing a picture of a sailboat in the water on your white board or flip chart. Explain to the team that some things push forward, like the wind, and some things slow your progress down, like an anchor.
  2. Idea Generation: Ask the team to identify what those items were.  List one item per sticky note, which are then placed on the boat.  As a facilitator, I will continue to tweak the seed questions I am using to keep the team thinking about the sprint from different angles.  You are done when the team is done.
  3. Insight Development: Have the team review the data and group ideas based on how they see the relationships between individual ideas. Techniques like Mute Mapping (grouping without talking) help to maximize team participation while minimizing the chance of a single person dominating.  Once THE grouping is done, I typically ask the team to name each group. This helps to cement the group’s understanding of the groupings of ideas that they have generated.
  4. Identify Improvement Objective: Select a group or specific idea to fix.  There are a number of techniques to select the improvement objective. Discussion followed by group consensus is one method (I use this when it is apparent that the group is close to consensus).  Another method is to vote using dots or post-it flags. In this method give each member a fixed number of flags and then ask them to vote (they can use all votes on one item or spread them).  The item or group with highest number of votes gets fixed first.

Examples of other listing techniques include:

The Four Ls – Use four categories: liked, learned, lacked, and longed for to generate ideas. Write these titles on four flip charts and place around the room.  Have each person silently generate ideas based on those categories.  When the team is done (i.e. everyone stops writing) have the team place their ideas (written on sticky notes) on the appropriate flip chart. Once the team has come up with their lists, identify the improvement objective, usually from the lacked or longed for category.

What Went . . . – Use four flip charts, put one of the following titles on each flip chart: what went well, what did not go well and what should we do more of and what should we do less of.  Brainstorm ideas to put on each flip chart.  Put one idea or statement on each sticky.  Depending on the group, this method can be done non-verbally (everyone puts their ideas on a set of stickies like the Four L’s) or have the team write ideas down and then shout them out (more akin to classic brainstorming). Insight development and identifying the improvement objective would follow a similar path to what was described above.

There are many other listing techniques each using a different set of seed questions (e.g. What worked well? or What would you like to do more of?) or different metaphors (e.g. sailboat, motorboats or trees). The questions or metaphors exist to help the team focus their discussion.  The metaphor or seed questions that are used need to make sense to the team’s culture, and also solicit areas that they are concerned about or can be improved. The Scrum Master or facilitator needs to use their observations about the team to select the retrospective technique that will provide the greatest benefit . I have seen teams of engineers that did not like using techniques that used metaphors (like the sailboat), while a UI team I worked with loved techniques that used metaphors. All of these techniques can work selecting which you will use is matter of team culture.

We will discuss techniques that are not list based here.

Related Entries:

Retrospectives: A Basic Process Overview

Retrospectives: Retrospectives versus a Classic Post-Mortem, Mindset Differences

Retrospectives: Obstacles

Retrospectives: Non-listing Techniques

Retrospectives: A Social Event

Scaffolding forms an obstacle to entering.

Scaffolding forms an obstacle to entering.

The power of a retrospective to improve a team’s ability to deliver business value is hard to deny. Given the demonstrable power of the technique, why does it occasionally fail to live up to expectations? Three (ish) primary issues that affect the value of retrospectives are ritualization, lack of follow through and management interventions.  These issues can cause the team or organization to enter a downward spiral of disillusionment that will inevitably end with the abandonment of the technique.

Ritualization:
The ritualization of retrospectives occurs when the process becomes more important (or at least as important) as the results.  There are numerous reasons for this issue, but we’ll tackle two here: overcommitted teams who don’t have time to reflect and boredom (wake me up when it’s over).  Teams that are so overburdened and can’t find a mechanism to get un-overburdened will always stay that way (a Catch 22). The ritual of the retrospective will usually be fulfilled so that they team can start planning the next sprint or iteration.  In essence, they need to check the process box so they move to the next step. The Scrum Master or coach needs to help the team address the root cause of the problem, whether that is team-driven over-commitment (taking too much work) to being told to take too much by management.  If a team is in an over-committed position more than occasionally, the Scrum Master may be part of the problem. That means that outside coaching is needed. If the root of the problem is technique boredom, the Scrum Master or another team member should learn another technique (such as timelines, the Sailboat, de Bono’s Thinking Hats or the 4 L’s).  All Scrum Masters should know at least nine techniques for retrospectives.

Lack of Follow Through:
The worst mistake any team can make is to perform a retrospective then do nothing with the results.  While the discussion itself may have been invigorating or cathartic, in the end the team wasted its time.  Consider that if you held a two hour retrospective with a team of eight people and then did nothing with the results you would have cumulatively wasted two full days of effort that could have been used to deliver value to your organization. Every retrospective should identify at least one goal or idea for improvement.  That goal should be added to the sprint backlog and addressed just any other piece of work that the team has committed to deliver. As soon as a team feels that their time is being wasted, they will begin looking for a reason to abandon retrospectives.  Teams that fall into this pattern should seek external coaching support to get back on track.

Note there is a specialized example of the “lack of follow through” syndrome that occurs occasionally.  Teams focus on issues in the retrospective that are outside of their ability to control. For example, I recently observed a team that was letting the fact that their office environment was noisy and that they could not have a dedicated team room consume them.  The organization had grown substantially and was attempting to find additional office space, but the process was taking longer than the team liked. The Scrum Master should have helped them understand that there were other process improvements that could be made or alternate mechanisms for addressing the issue, rather than fixating on an issue they could not control.  In the end, the team had a heart-to-heart discussion with the owner, which mollified the team (they did understand the status of the expansion plans).  The team also received training on retrospectives and facilitation.

Management Interventions:
Retrospectives, are a team exercise.  In a sprint retrospective the team is comprised of a Scrum Master (or coach), Product Owner and development team.  No one else, with the exception of an occasional outside facilitator, should attend. As soon as managers or other outsiders begin attending the conversation will change to become more guarded and territorial.  In my experience when outside observers are included, the goal often shifts from process improvement to position improvement.  The Scrum Master must make every effort to police the team boundary and ensure the free flow of information within the retrospective.

The retrospective can’t become ritualized to the point that it lacks meaning.  Each retrospective needs to provide a platform for the Agile team to reflect on their performance and to determine how they can achieve more. This is a team activity that requires a free flow of conversation and ideas in order to maximize effectiveness. That means someone needs to facilitate the process and police the boundary.  No team is perfect and all teams can learn and improve on a continuous basis.  Most obstacles to effective retrospectives are solvable with a bit of coaching and education if you recognize the obstacles before you abandon the technique.

Related Entries

Retrospectives: A Basic Process Overview

Retrospectives: Retrospectives versus a Classic Post-Mortem, Mindset Differences

Retrospectives: Listing Techniques

Retrospectives: Non-listing Techniques

Retrospectives: A Social Event

The team owns the results of a retrospective!

The team owns the results of a retrospective!

Early in the adoption of Agile of someone will often ask, “What is the difference between an Agile retrospective and the classic postmortem?” Three mindset differences stand out in particular:  action, permission and ownership.

Action:
Tim Lister made one of the most important comments I have ever heard on the idea of “lessons learned”. Tim said, in essence – if the end-of-project lessons learned were really important, then we would begin every project with an obligatory reading of lessons learned. I have never seen that ritual performed. Agile retrospectives occur at point of usefulness, rather than at the end of the project. They are about changing how the project is being done now rather than about how a project might be done later. The bias in the Agile retrospective is for taking action today rather than action tomorrow.

Permission:
The second major mindset difference is a focus on the meeting the needs of the Agile team, rather than addressing the needs of the standard process. Agile retrospectives focus on how work is being done today which involves scrutinizing team skills, capacity and processes. The retrospective is about finding changes that will allow the team to deliver more value than the last sprint. The team is in charge of identifying and making changes. The team doesn’t need to ask for permission to make changes. In a classic postmortem, because the focus is on the standard process, the team can only make recommendations.  Why the focus on the standard process? Because classically at the end of a project teams are disbanded and reformed, therefore findings that involve how individuals work together do not make sense.

Ownership:
This final mindset difference may sound a bit repetitive, but it is not. An Agile retrospective is a team tool, whereas the classic postmortem is done for the organization (e.g Engineering Process Group or management). Postmortem attendees can include anyone involved in the project or supporting the process. Classic postmortems collect information about the project for later use. Whether metrics, process improvement recommendations or lessons learned, the information is collected for posterity. The deliverable of a postmortem is a formal report that may well become shelfware. Participation in an Agile retrospective generally only includes core team members – the Scrum Master, the development team and the Product Owner.   The only deliverable generally created is notes that are taken needed to plan actions for the next sprint or about obstacles that the Scrum Master will focus on removing. Any documentation that is created is for the team and not for consumption elsewhere.

The differences between Agile retrospectives and postmortems boil down differences in mindset.  Agile retrospectives have a bias for action.  Agile retrospectives are about making changes in how work is being done.  The team does not need permission to make the changes demanded by an Agile retrospective. Finally Agile retrospectives are done to help the team, rather than a means of validating and maintaining a standard process.

Related Entries

Retrospectives: A Basic Process Overview

Retrospectives: Obstacles

Retrospectives: Listing Techniques

Retrospectives: Non-listing Techniques

Retrospectives: A Social Event

Don't gamble on team issues resolving themselves.

Don’t gamble on team issues resolving themselves.

Retrospectives are part of most methodologies, even though there are many different terms. For instance, most waterfall frameworks call them post implementation reviews or postmortems. And each methodology focuses on different nuances. Agile, as a macro set of frameworks, has more aggressively embraced retrospectives than waterfall or iterative frameworks.  Retrospectives in Agile reflect the adoption of the principle of kaizen (Japanese for improvement, often interpreted as continuous improvement). They should be focused on discovering what will make the team or organization deliver more value. While many retrospective techniques posit the questions “what worked well” and “what did not work,” the real reason to do any retrospective is to identify, agree on and plan for what can be done better. The exact process any team uses is a reflection of the technique the team wants to use, what works in the organization and the specific team situation. For example, the timing of retrospectives varies significantly depending on the framework and the organizational culture.  Most waterfall projects do a retrospective at the end of the project (or release), while Agile projects typically do retrospectives at the end of every sprint, at each release, at the end of the project and occasionally on an as needed basis.  In Agile, retrospectives occur when change can actually be applied to the project to impact the current delivery.

This is the basic process for a typical end-of-sprint retrospective:

  1. Set Up:  First, create a safe atmosphere (I review Norm Kerth’s Prime Directive with the team). Then ground the team by focusing on the current sprint’s results (for example review the Burn-down Chart or have the team develop an annotated sprint timeline). Time box this part of the retrospective to no more than 20 minutes for a two week sprint.
  2. Idea Generation: Encourage the team to dig in and capture the details.  For retrospectives focused on process or flow, I often use sticky notes to brainstorm, followed by mute mapping to group (affinity diagraming). For team or personnel issues, I use storytelling. For example, have subsets of the team describe a fictional scenario based on real life problems and how they would solve the problem. I have also used direct discussion. This step should be time boxed to 30 minutes for a two week sprint.
  3. Insight Development:  Once the idea generation step is completed, the team reviews the data and comes to a consensus about what it means. One method of analysis is to look for patterns and to determine if there are trends in this stage.  The goal is to recognize if there is a problem so you can start to resolve it.
  4. Identify Improvement Objective:  In many cases a team might have identified a number of ideas for improving their productivity. Focus on the top one or two big wins.  The rational for not fixing everything is first that the time need to fix the problem will come from the team’s capacity to deliver business value (there is only so much capacity that the team has at its disposal).  Secondly, if the remaining issues are really problems after the one or two most important have been dealt with then the team can decide to address them during the next iteration. FYI, this continuous incremental process improvement is one reason team productivity, aka velocity, typically increases from iteration to iteration.  After the team selects the issue (or issues) to be tackled, have them add it to the next sprint backlog so that they get addressed.  This step should be time boxed to 30 minutes for a two week sprint.
  5. Wrap-up: Spend 5 – 10 minutes reviewing the session so that the next retrospective will be even more effective.

Retrospectives are a tool that the team uses to identify what they can do better.  The basic process – making people feel safe then generating ideas and solutions so the team can decide on what they think will make the most significant improvement – puts the team in charge of how they work.  When teams are responsible for their own work, they will be more commitment to delivering what they promise. The retrospective process is focused on increasing the team’s capacity, rather than trying to generate lessons learned for the next project.

Related Entries

Retrospectives: Retrospectives versus a Classic Post-Mortem, Mindset Differences

Retrospectives: Obstacles

Retrospectives: Listing Techniques

Retrospectives: Non-listing Techniques

Retrospectives: A Social Event

20130421-072751.jpgI

The Agile technique of performing a retrospective at the end of every sprint is a powerful mechanism to understand the issues affecting your team. Part of the power of the technique is that since sprints are generally short (one to four weeks, with most being in the two week range), it is possible to address an issue as a team and then to expect quick feedback on progress toward resolution. The retrospective and washing your hands with soap and water are similar. Both represent a means to remove impurities that can sicken the team.

Note: I am publishing this blog from China. If the pictures are missing or garbled I will correct when I return.