Conduct retrospective

Conduct retrospective2018-05-31T09:37:18+00:00

Retrospective Workflow

Context

Summary

Provide a summary of this practice.

The Retrospective is the team meeting held at the end of each iteration to evaluate the work done during the iteration and identify lessons learned.

Purpose

What is the overall goal or intention of this practice?

The purpose of a Retrospective is to provide the team with an opportunity to discuss systematically how to improve their ways of working for the remainder of the work.

SLA

What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?

A Retrospective normally lasts 30 to 60 minutes.

Exit conditions

What must have happened or been delivered for this practice to be considered complete?

The Retrospective is complete when:

  • All team members are satisfied that their concerns and experience have been reviewed.
  • An approach to implementing the items identified has been agreed.

Entry conditions

What pre-conditions must be met before this practice is used?

A retrospective is usually the last task in an iteration.

Outline process

This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.

#StepInstructions
1 Muster team
  1. The Iteration Lead invites all team members and the Product Owner to attend the Retrospective.
2Review work
  1. The Iteration Lead reviews the team’s progress on any actions agreed at the previous Retrospective.
  2. Once assembled, the group normally addresses the following questions:
    • What (especially innovations) has worked well with regard to people, process, and tools?
    • What obstacles were met or are expected in future?
    • Does the ‘Definition of Done‘ need to be revised?
    • What do the team want to change for the remaining iterations of this release?
    • Did the team’s velocity match their expectations? If not, do the team need to adjust their future Iteration Plans?
  3. Each team member is asked in turn for issues and suggestions.
3Plan improvements
  1. Once all participants have spoken, they discuss how to implement any items that require substantial change.
  2. The final list of impediments and improvements is recorded on the team’s Improvement Board.
  3. A plan of action is agreed.
  4. Where appropriate:
    • Individual team members commit to specific changes.
    • The Product Owner agrees to raise issues with external parties.
4Close meeting
  1. The Iteration Lead checks that all participants are happy with the outcome of the Retrospective:
  2. They do this by checking with each participant (i.e., one at a time) that:
    1. The meeting covered everything that was important to them.
    2. They were able to speak freely.
    3. They believe that the agreed actions will bring about the improvements they want to see.
5Follow up actions
  1. The Iteration Lead tracks progress against the improvement plan and updates the Improvement Board.
  2. The team’s achievements are reported (and where appropriate celebrated) at the next Retrospective.

Detailed process

#StepByOutputInstructionsNotes
1 Muster teamIteration Lead.

Team.

Product Owner.

  1. The Iteration Lead invites all team members and the Product Owner to attend the Retrospective.
  • To encourage frankness, the meeting should take place in a private location where the team will not be overheard.
  • Check that the participants are comfortable with the location.
2Review workIteration Lead.

 

Team.

Product Owner.

  1. The Iteration Lead reviews the team’s progress on any actions agreed at the previous Retrospective.
  2. Once assembled, the group normally addresses the following questions:
    • What (especially innovations) has worked well with regard to people, process, and tools?
    • What obstacles were met or are expected in future?
    • What do the team want to change for the remaining iterations of this release?
    • Did the team’s velocity match their expectations? If not, do the team need to adjust their future Iteration Plans?
  3. Each team member is asked in turn for issues and suggestions.
  • Contributors speak without interruption.
  • It can become wearing to always be asked the same formulaic questions, so try to vary the approach.
    • Ask what each team member has learned since the previous Retrospective.
    • Explore the team’s relationship with the Extended Team.
    • … and with the users.
    • Does the ‘Definition of Done‘ need to be revised?
    • What experiments could the team try?
    • Etc.
3Plan improvementsIteration Lead.

Team.

Product Owner.

  1. Once all participants have spoken, they discuss how to implement any items that require substantial change.
  2. The final list of impediments and improvements is recorded on the team’s Improvement Board.
  3. A plan of action is agreed.
  4. Where appropriate:
    • Individual team members commit to specific changes.
    • The Product Owner agrees to raise an issue with external parties.
  • The best actions are:
    • Tied not just to a clear purpose but also to an explicit, ideally quantifiable, benefit.
    • Small enough to be doable before the next Retrospective.
    • Within the understanding and capabilities of the Core Team members they are assigned to.
    • Visible to the rest of the team.
  • Prioritise actions according to (and by striking a balance between):
    • Effectiveness – do the ones that will solve the most important problem first.
    • Efficiency – maximum effect for minimum action.
4Close meetingIteration Lead
  1. The Iteration Lead checks that all participants are happy with the outcome of the Retrospective:
  2. They do this by checking with each participant (i.e., one at a time) that:
    1. The meeting covered everything that was important to them.
    2. They were able to speak freely.
    3. They believe that the agreed actions will bring about the improvements they want to see.
It is not always easy to check that the participants are really happy with the outcome of the Retrospective, especially with a new Agile team or team member.

These are basic facilitation methods you might consider:

  • Positively ask each individual for their contribution on each point.
  • Always make it clear how positively alternative views & dissent are valued.
  • Be patient, especially with individuals who have not previously contributed.
  • Value & reinforce small contributions as well as large ones.
  • Try to build participants’ confidence over successive meetings by working with them between Retrospectives.
  • Check that the right person is facilitating the retrospective.
5Follow up actionsIteration Lead.

Team.

Product Owner.

  1. The Iteration Lead tracks progress against the improvement plan and updates the Improvement Board.
  2. The team’s achievements are reported (and where appropriate celebrated) at the next Retrospective.
  • It may be appropriate to raise each improvement as an story for implementation during the next iteration.

Issues & risks

What are the key concerns in making a success of this practice?

  1. Retrospectives are usually attended by the iteration team only.
    • Other stakeholders may attend only if the team invite them.
    • Other SMEs and specialists (e.g, independent testers) who participated actively in the iteration may also be invited.
  2. Leading a Retrospective is a significant skill.
    • If the normal lead does not believe that they have the necessary skill or experience, they can be replaced by another Iteration Lead from the same organisation or any other person with specific facilitation skills.
      • However, note that, the further the Retrospective lead’s experience is from this team and its current work, the less they are likely to be able to raise insights, identify improvements and motivate action.
    • Ice-breaking activities (games, etc.) can facilitate the process. However,
      • A team that still needs ice-breakers after working together so intensively may have deeper issues.
      • Avoid forcing shy team members into participating in games. They can be very embarrassing and counter-productive.
      • Likewise for multi-cultural groups: a ‘ice-breaker’ that is acceptable or fun for one culture can be offensive or humiliating for another.
    • Master the skill of progressing from discovery-oriented ‘open’ questions (‘How do you think x went?’) to actionable ‘closed’ questions (‘What specifically do we need to change to achieve stop y happening again?’). But avoid making the transition too hasty.
  3. Improvement should be being posted on the Improvement Board throughout the iteration – they should not be waiting for the formal Retrospective.
    • Likewise, actions should be assigned and executed as soon as the right person becomes available and the opportunity arises.
  4. Make sure you don’t just focus on improving things you already do well – the focus should be equally (if not more) on things that went wrong, errors, broken relationships, role, process and tools usability and performance, etc.
  5. Ensuring active participation by the whole team can be a major problem.
    • Retrospectives are intended to be brief, and the speed and intensity of the process can easily hide:
      • Reticence (e.g., silence or extremely brief responses to direct questions).
      • Evasion and detachment (e.g., providing only brief, yes/no answers to complex, ‘open’ questions).
      • Distraction (e.g., by phone, email, late work, etc.).
    • See here for some useful techniques for dealing with passivity, etc.
  6. A release-level Retrospective can also be valuable, especially for a team that expects to remain together for future releases (e.g., a Product Team).

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?