Why Should I Have More Than One Technique for Retrospectives?

Scope of This Report

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. 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.  

Brian Wernham, in Agile Project Management for Government noted the UK DirectGov project used retrospectives to mold how the worked in order to maximize delivery productivity. 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.

Obstacles

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? 

Ritualization:

Ritualization can dramatically affect the value of retrospectives. Ritualization can cause the team or organization to enter a downward spiral of disillusionment that will inevitably end with the abandonment of the technique.

The ritualization of retrospectives occurs when the process becomes more important than (or at least as important as) the results.  There are two typical reasons that cause ritualization: overcommitted teams who don’t have time to reflect and boredom (wake me up when it's over). Gil Broza in The Human Side of Agile notes that” Works Well and Needs Improvement format gets really old quickly.” 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. 

Process:

A basic process for a typical Agile, end-of-sprint retrospective:

  • Set Up: First, create a safe atmosphere (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.
  • Idea Generation: Encourage the team to dig in and capture the details.  For retrospectives focused on process or flow, use sticky notes to brainstorm, followed by mute mapping to group (affinity diagraming). For team or personnel issues, 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. Consider direct discussion as an alternative. This step should be time boxed to 30 minutes for a two week sprint.
  • 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.
  • Identify An 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 actionable 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. Also, trying too many changes at once makes it hard to track cause and effect.  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 it gets addressed.  This step should be time boxed to 30 minutes for a two week sprint.
  • 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.

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.  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 obstacles. 

List Generation Techniques

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.  We discussed the basic Affinity Diagraming technique above.
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 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.  We discussed the basic Affinity Diagraming technique above.

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:

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.

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, continue to tweak the seed questions you are using to keep the team thinking about the sprint from different angles.  You are done when the team is done.

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, ask the team to name each group. This helps to cement the group’s understanding of the groupings of ideas that they have generated.

Identify An 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 (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. All of these techniques can work, selecting which you will use is matter of team culture.

Other Techniques

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:

  • Have each team member silently write down on sticky notes the major events, from their perspective, using the color code from above.
  • 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
  • Throw out duplicates.
  • Have the team select someone to walk through the final timeline.
  • Using the dot voting technique (provide each team member with three dots) rank the event that slowed the project down the most to date.
  • Identify tasks and actions that could be taken to solve the problems. Pick the top two or three.
  • 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).  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”:

1. Blue Hat (5 minutes) – focus on discussing session objectives.
2. White Hat (10 minutes) – discuss or identify FACTS or information since the last sprint (e.g. we had a hurricane during this sprint).
3.  Yellow Hat (10 minutes) – talk only about the good things that happened since the last retrospective.
4. Black Hat (10 minutes) – talk only about the bad things that happened since the last retrospective.
5. Green Hat (10 minutes) – talk only about ideas to solve the identified problems or ideas that would add more significant value in the Product Owner’s perception.
6. 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.

Finally, have the 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.

Coaching a Retrospective

Facilitation skills, choice of technique and the tools that are used, in that order, will impact the effectiveness of retrospectives. The degree of team distribution will cause the degree of importance of the attributes to vary. For instance, distributed teams will have to lean on communication tools to a greater extent.

At their heart, all retrospectives are social exercises. Even in well-honed teams it is an ongoing challenge to keep team member talking and sharing in a manner that will convey information without damaging relationships. As Naomi Karten pointed out in her interview on the Software Process and Measurement Cast, there are a relatively high proportion of introverts in IT who need help in order to be drawn out. The facilitator’s skill at getting people to interact is more important as the degree of team is distribution increases. In distributed teams, the facilitator needs to find ways to make the team’s interactions more personal. For example, making sure everyone talks and that location bias does not set in. An interesting technique to defeat this issue is to pair individuals from different locations as homework for the retrospective. In one example DCG facilitated, a Scrum Master asked each pair to collaborate and identify five ideas to improve collaboration, while another time (with different sets of pairs) the Scrum Master asked the groups to do a five minute overview on an upcoming local holiday. The goal was to make sure the locations were talking and that the whole team was exposed to the different cultures on the team, which fosters deeper communication.

Different retrospective techniques will evoke different responses from participants. For example, a timeline retrospective will focus on events. A classic list generation-based retrospective will focus on process. Picking the right type of retrospective gives a facilitator the chance at opening up the team. The technique selected for a retrospective is generally a balance between the focus and technique satisfaction (i.e. how many times you have used the technique as over use causes boredom). When coaching long-term projects, teach the team a variety of techniques and then let them select the technique that they want to use. Remember to add techniques or remove techniques from the team playbook as the situation warrants.

Conclusions

Every retrospective requires some sort of tool. Tools can be as simple as a white board and markers or as complex as mind-mapping and screen-sharing software. When a team is distributed, screen sharing and teleconferencing/videoconferencing tools are necessities. The combination of technique and level of team distribution will influence tool selection. Likewise, tool availability will influence technique selection. For example, use a mind mapping tool and screen sharing when executing a listing retrospective for a distributed team so that each location can see the ideas and participate. If the distributed team could not use those tools, you will have to find a different approach. Generally the technique defines the toolset, but that is not always the case. When everyone is in the same room sticky notes are great but when team members are teleconferencing into the retrospective electronics are required.

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. Facilitation skills, retrospective techniques and tools are all important for an effective retrospective. The technique is driven by needs of the team. The coach/facilitator needs to be aware of the needs of the team and the proper tools to facilitate the technique. If they are not available, pick another technique. However once the retrospective begins, facilitation skills are always the most important factor. Even with the best technique and tools, retrospectives are all about the people.

Sources:

  • Agile Project Management for Government, Brian Wernham, Maitland and Strong, 2012, P 195
  • Norm Kerth’s Prime Directive, http://www.retrospectives.com/pages/retroPrimeDirective.html
  • The Human Side of Agile, Gill Broza, 3P Vantage Media, 2012, P. 172
  • The Agile Mind-Set, Gil Broza, 3P Vantage Media, 2015, 149
  • De Bono’s Six Thinking Hats, https://en.wikipedia.org/wiki/Six_Thinking_Hats
  • http://spamcast.libsyn.com/s-pa-mcast-244-naomi-karten-how-to-survive-excel-and-advance-as-an-introvert

Download this Trusted Advisor report here.

Written by Default at 05:00
Categories :

What to Expect With SAFe 4.0

We’re pleased to announce the latest version of the Scaled Agile Framework (SAFe) has been released –SAFe 4.0 for Lean Software and Systems Engineering!

We are SAFe Silver Partners. This, of course, means that we’re big proponents of the framework (when implemented properly), and as such, we offer SAFe-related training courses, services and consulting.

We also have three certified SAFe Program Consultants (SPCs) in our company: Mike Harris, Tom Cagley and Tony Timbol – all of whom are available to offer SAFe guidance and run SAFe courses. We’re excited to share that they are all now officially certified in SAFe 3.0 and SAFe 4.0, having passed the official exam that covers the latest updates to the framework.

What are those updates? Well, any framework worth its salt is going to appropriately evolve over time based on industry feedback – and SAFe is no exception. Version 4.0 offers a single, more scalable framework that includes new content and guidance to help organizations better organize around value delivery and improve the coordination of value streams and systems.

Some highlights:

  • SAFe now supports both software and systems development.
  • Enterprise Kanban systems manage the flow of work across all levels.
  • The Big Picture is simpler and lighter weight.

We won’t get into all the details here. You can read more about the update on the SAFe website or join Tony Timbol for a webinar on January 21 to review the changes from 3.0 to 4.0. If you have any questions, you can always contact us for more information – we’re always happy to help!

Written by Default at 05:00
Categories :

Is Function Point Analysis Valuable in an Agile Environment?

Tony MannoMany organizations are embracing Agile as their development framework of choice. The Agile project team, consisting of a Product Owner, Scrum Master and developers, creates and prioritizes user stories, which describe the functionality to be delivered by completion of the task/story. The team plans and executes in sprints to develop and implement functionality for each user story, and updates and reprioritizes the backlog of user stories (backlog grooming) for each subsequent sprint. By working in this way, Agile provides faster realization of value through incremental delivery of functionality, prioritizing the deliverables that will have the most impact. It involves the user in the development process, reduces risk by identifying issues earlier in the project lifecycle and embraces change throughout the project. It’s easy to understand why it’s become such a popular framework!

As in traditional waterfall, Agile project teams have a responsibility to the business to deliver on time and within budget. An estimate of the overall project spend and schedule can be done at the beginning of the Agile project and modified throughout the lifecycle to ensure accuracy as project requirements change. Project metrics can be derived at the end of the project and compared within the company portfolio or to industry benchmarks. But, the question is how to do this.

The answer, of course, is Function Point Analysis. Function Point Analysis is a standardized method for measuring the functionality delivered to a user, independent of technology. It works well for Agile and traditional waterfall projects. Function Point Analysis can be used at the beginning of an Agile project, once the user stories have been defined. Cost and duration estimates can be derived for the overall project from the function point counts using well defined, industry proven models and software. At the end of the project, metrics such as productivity, defect density and time-to-market are valuable in the Agile environment as within waterfall. These metrics allow measurement for internal improvement initiatives, contract compliance and comparison to industry benchmarks.

Estimation and project metrics based on functional sizing are good practices, regardless of the delivery framework used. They allow the project team to provide the business with realistic expectations of project cost and duration and to measure themselves against improvement goals and the industry.

For more insight on the use of function points in an Agile environment, check out the July 2015 DCG Trusted Advisor report, “Story Points or Function Points or Both?”


Tony Manno
Vice President, Outsourced Services

Written by Tony Manno at 09:46
Categories :

Top Blog Posts of 2015

David Consulting Group BlogEvery year we like to share the most-read blog posts on our site for that period of time. It's a great way for our readers to catch up if they've missed a particular post, and it also highlights what other readers are finding interesting or compelling on our site.

So, without further adieu, here are the top 5 blog posts from 2015:

  1. Estimating Software Maintenance - A post from David Herron discussing an interesting article he read that presents a unique and proven approach for estimating maintenance and support activities using a new type of "sizing" model.
  2. Scaling Agile Testing Using the TMMi - This post from Tom Cagley invited readers to register for his webinar on the topic. Obviously the webinar itself is over, but you can read the post and then access the recording of the webinar here.
  3. Agile Transformation of the Organization - This post from Mike Harris discusses how to successfully implement enterprise Agile.
  4. The Value Visualization Framework - This post provides an overview of the Value Visualization Framework (VVF), developed by Mike Harris to address the fact that most software initiatives are driven by technology and time-to-completion rather than economic value.
  5. How To: Manage Vendor Performance - Another post from David Herron! This time David dives into third-party vendors, addressing the questions: How do we measure value delivered to the business? How do we equate cost to value? How can we ensure that we are getting a good price for the value being delivered?

As you can see, our readers are interested in a fairly wide variety of topics! Did one of your favorite posts not make the cut? Leave a comment letting us know!

We look forward to sharing more posts in 2016!

Written by Default at 05:00

Top Publications of 2015

Our goal here at DCG is to always provide value to our readers, our clients and those in the software industry. As such, we share a lot of content that addresses a variety of software-related topics and provides information that we hope will facilitate problem solving or just provoke a thought or two.

With so much content, it's easy to miss an article now and again. With that, we'd like to share our top publications of 2015, based on traffic as well as feedback we've received.

First, we'd be remiss not to share our template for contracting for Agile. It was not written or published in 2015, but its popularity and usefulness is undeniable!

And now, for the top 5 publications of 2015:

  1. An Introduction to the Scaled Agile Framework - This article is an overview of the framework and why (and when) you would want to use it in your organization.
  2. Five Problems that Impact Testing Effectiveness and Efficiency - This article outlines five typical causes of testing issues and how to combat them.
  3. The Average Size of a Project - We did some rough calculations to determine the average size of our software development projects. In thie article, we share our data!
  4. 6 Steps to An Estimation CoE - This article outlines the steps to establish a robust Estimation Center of Excellence.
  5. Finding the Right Service-Level Measure in a Changing Outsourcing Landscape - Establishing a contract for outsourcing is tough. This article discusses how to create service-level agreements that measure both cost and value.

Of course, those are just the top 5! There are plenty more to be found in our Publications Library - and there will be more to look forward to in 2016!

Written by Default at 05:00

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!