why should i have more than one technique for retrospectives? · –6 thinking hats retrospective...

Phone: +1-610-644-2856

Measure. Optimize. Deliver.

softwarevalue.com

Why should I have more than one

technique for retrospectives?

Making Software Value Visible.

©2016 DCG Software Value

Agenda

• About Us

• Why Retrospectives?

• Typical Process

• Obstacles

• List Generation Techniques

• Other Techniques

• Strategic Retrospectives – AgilityHealth Radar

1


ANALYTICS QUALITY AGILE

• Code Analytics

• M&A Analytics

• Software Estimation

• Software Metrics

• Software Vendor

Management

• Training

• Business Value of IT

• CMMI

• Program Rescue

• Project Triage

• Software Code Quality Review

• TMMi®

• Training

• Agile Competency Development

• Agile Estimation

• Agile Project JumpStart

• Agile Project Reboot

• Agile Readiness Review

• Agile Team Coaching

• AgilityHealth Radar

• Executive Workshop

• The Scaled Agile Framework®

• Training

Build | Operate | Transfer

Consulting


Why Retrospectives?

• Retrospectives are part of most methodologies, even though there are many

different terms (e.g. post-implementation reviews or postmortems).

• Each methodology focuses on different nuances. Agile more aggressively

embraces retrospectives than waterfall or iterative frameworks.

• Retrospectives in Agile reflect the adoption of the principle of kaizen (Japanese

for improvement [continuous improvement]):

– Discover what will make the team or organization deliver more value.

– Retrospectives occur when change can actually be applied to the project

to impact the current delivery.

• Brian Wernham, Agile Project Management for Government, noted the UK

DirectGov project used retrospectives to mold how teams worked in order to

maximize delivery productivity.

3


Why Retrospectives?

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.

4


Typical Process

• Set Up (<20 minutes for a 2 week sprint):

– First, create a safe atmosphere (review Norm Kerth’s “Prime Directive” with the team).

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

• Idea Generation (<30 minutes for a 2 week sprint):

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

• 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 (<30 minutes for a 2 week sprint):

• Wrap-up: Spend 5 – 10 minutes reviewing the session so that the next retrospective will

be even more effective.

5


Typical Process

Identifying an Improvement Objective

• A team may have identified a number of ideas for improving its productivity.

• Focus on the top 1-2 actionable “big wins.”

• The rationale for not fixing everything:

– The time needed to fix a 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).

– If the remaining issues are really problems, the team can decide to

address them during the next iteration.

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

6


Obstacles

Ritualization

• Ritualization can dramatically affect the value of retrospectives.

• Downward spiral of disillusionment that will inevitably end with the

abandonment of the technique.

• Two typical reasons that cause ritualization:

– The process becomes more important than (or at least as important as)

the results.

– Overcommitted teams who don’t have time to reflect.

– Boredom (wake me up when it's over). The “Works Well” and “Needs

Improvement” format gets really old quickly. The retrospective will usually

be fulfilled so that they team can start planning the next sprint or iteration.

• The Scrum Master or coach needs to help the team address the root

cause of the problem.

• All Scrum Masters should know at least nine techniques for

retrospectives.

7


Obstacles

Culture

• Retrospectives are a tool that the team uses to identify what they can

do better BUT the basic process can all go wrong:

– Making people feel safe

– 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

• If the retrospective process is focused on increasing the team’s

capacity rather than trying to generate lessons learned for the next

project, then non-obvious impediments can easily be missed.

• There are many different techniques for executing retrospectives;

many teams find 1-2 techniques they like, and then they ride that horse

until it collapses.

• Lean thinking removes processes that don’t add value!

8


List Generation Techniques

Affinity Diagraming

9



Sailboat (1)

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

10



Sailboat (2)

• 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 you 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 1 item per

sticky note; place them 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.

11



Sailboat (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, ask the

team to name each group. This helps

to cement the group’s understanding

of the groupings of ideas that they

have generated.

12

+

Different

Metaphors



Sailboat (4)

• 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 (use this when it is

apparent that the group is close to

consensus).

– Vote using dots or post-it flags. 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.

13

+

Different

Metaphors



The Four Ls

• Four categories to generate ideas:

– Liked

– Learned

– Lacked

– Longed For

• 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 its lists, identify the improvement

objective, usually from the lacked or longed for category.

14



What …?

• Use four flip charts, put one of the following titles on each flip

chart:

– What went well?

– What did not go well?

– What should we do more of?

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

15

+

Different

Seed

Questions



Thorns and Roses

• Go around the team asking for one

thorn (something that could be

improved) and one rose (something

that went well and should be

reinforced) from each team member.

On the first round, each team

member must provide one of each.

• Repeat until there are no more

thorns or roses.

• Insight development and identifying

the improvement objective would

follow a similar path to what was

described above.

16


Other Techniques

• These techniques deal with more complex issues. They 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 difficult to execute:

– Timeline Retrospective

– 6 Thinking Hats Retrospective (based on De Bono’s Six Thinking Hats).

– Emotional Trend Line – Often 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.

17

http://en.wikipedia.org/wiki/Six_Thinking_Hats


Timeline Retrospective

• 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 colorblind participants may have

difficulty).

• When To Use:

– The Timeline Retrospective is useful for refreshing and re-grounding the

memories of team.

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

– An end of project retrospective.

18


Timeline Retrospective in Action

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

– Blue = good events

– Yellow = significant events (neither good nor bad)

– Red = problem events

19


Timeline Retrospective in Action

• The process:

– 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 the 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

choices.

20


6 Thinking Hats Retrospective

• Use this type of approach when:

– The team has experienced significant challenges.

– The team has not established norms on how to interact.

– The team tends to be dominated by 1-2 personalities.

• 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 (collective thinking).

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

21


6 Thinking Hats Retrospective in Action

• 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 ideas that 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.

• 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 1-2 actions that will improve the ability of the team

to deliver and add them to the backlog for the next sprint.

22


Strategic Retrospectives

DCG AgilityHealth Radar Team Assessments

• Three-hour facilitated workshop that focuses on the top areas that

affect team performance and health:

– Step One: Facilitator works with team to complete the 360 TeamHealth

Radar, covering the 5 key dimensions of a healthy Agile team: Clarity,

Performance, Leadership, Culture, Foundation.

– Step Two: The instructor will engage the team in a healthy and open discussion

around analyzing its radar results and reviewing its Strengths, Improvements and

Top Impediments to growth. The final output is a team Growth Plan with key

outcomes the team wants to achieve within the next few months.

• The real value from this workshop is the open and honest

conversations to help the team get past any current roadblocks and

develop a clear plan of action for getting their performance and health

to the next level.

• Repeat this strategic retrospective each quarter as a refresh on the

“per sprint/iteration” retrospectives

23




24




25




• Report Contents:

– AHR Charts

– Top 5 and Lowest 5 Competencies

– Top 5 and Lowest 5 Consensus Competencies

– Notes by 5 key dimensions and for last 3 questions:

• Strengths

• Improvements

• Impediments

– Growth Plan

26


To Summarize:

• The Scrum Master or coach needs to help the team address the root

cause of the problem.

• All Scrum Masters should know at least nine techniques for

retrospectives.

1. Affinity Diagramming

2. Sailboat

3. The 4 Ls

4. What …?

5. Timeline Retrospective

6. 6 Thinking Hats Retrospective

7. Emotional Trend Line

8. Complexity Retrospective

9. DCG’s AgilityHealth Rader TeamHealth Assessment

27


Contact Us

Email: [email protected]

Phone: 1-610-644-2856

http://www.softwarevalue.com

28

@DCGSWValue

/DCGSWValue

/company/DCG-Software-Value

Measure. Optimize. Deliver.

softwarevalue.com

http://www.URL.com

why should i have more than one technique for retrospectives? · –6 thinking hats retrospective...

Documents