Continuous improvement

Introduction

Continuous improvement is the practice of iteratively reviewing processes and impediments and making incremental changes to reduce waste and increase quality.

This is a set of defaults for teams to use, but is not mandatory if teams have good reason to do something different (see What this is — and is not).

Essential reading

Continuous Improvement describes the theory and practice and is essential reading.

Recommended defaults

• Run a retrospective every two weeks with everyone in the team involved, including the product owner.
  • Feel free to vary the format (e.g. funretrospectives, agilestrides), but make sure you focus on celebrating what is working well, identifying things which are not working well and deciding actions to improve. A mix of general "anything goes" sessions and others focused on a specific topic can work well.
  • Make sure everyone's voice is heard.
  • Take turns running the retrospective, rather than always letting the same person do it.
• For actions which involve maintaining focus on agreed practices, build these into your workflow, for example as a daily reminder during stand-up or in your exit criteria for a particular workflow stage.
• For actions which are about doing something (such as setting up a regular joint planning session with another team) create a backlog item and deliver it as part of your usual work.
• As described in the essential reading article, it can be helpful to focus on a specific area in which to drive improvement using the Kata format to set the context for individual improvement experiments.
• Use measurement to guide improvement. A good starting point is to use a set based on the State of DevOps metrics:
  • Lead time
  • Deployment frequency
  • Change fail rate
  • Total incident rate (by incident severity)
  • Time to restore service (by incident severity)

Valuable retrospectives

Signs retrospectives are working well are:

• Improvements and experiments are identified, enacted and learned from.
• Team members have the empowerment and courage to discuss difficult problems.
• Discussion happens during the meeting.

Watch out for

• Make sure the retrospective is a safe space where team members can talk freely. Be wary of external stakeholders attending as this may stifle open and honest discussion. Where stakeholders feel strongly they need to be involved, consider running two separate retros: one for the team and another with external parties involved.
• Watch for the same topics being raised repeatedly. This may suggest the team feels powerless to change its own process or address issues and will erode team morale. Help the team think creatively about potential solutions and consider escalating issues if necessary.
• Don't allow retrospectives to be routinely skipped in favour of other work. It is important to hold regular retros, and arguably they are most valuable at times when there is a feeling that time pressures do not allow it as a way to uncover and identify ways to alleviate the causes of the pressure. In particular, be wary of people from outside the team questioning the value of the retrospective or suggesting time is best spent elsewhere, making sure you clearly explain the importance of retros in a way they understand.