Continuous improvement

Continuous improvement is the habit of looking at how we work, finding what could be better, and changing it in small steps. It is everyone's job, it focuses on processes rather than people, and it only counts if the change sticks.

Principles

• Everyone takes part. The people doing the work see the problems first.
• Fix the process, not the person. When something goes wrong, ask what in the system allowed it.
• Small steps. Incremental change carries less risk and compounds.
• Root causes, not symptoms. Keep asking why until the answer is something you can change.
• Feedback loops. Shorten them, and pay attention to what they say.
• Adaptability and sustainability. Be open to new information, and keep reviewing whether an improvement has held.

How we do it

Retrospectives. Every team reflects regularly, usually every two weeks, on what went well and what to change, independent of any particular event. After action reviews do the same for a specific milestone, release or incident; see Operation and support.

Team health checks. About once a quarter, each team steps back and scores its own health across a set of topics. The topics cover ease of release, process, technical quality, value, speed, mission, fun, learning, support, and whether the team feels in control of what it builds. The scores are sentiment, not objective truth, and that is the point: the team's concerns are heard and acted on, starting with the quickest wins. Repeated checks, and comparison across teams, show trends and surface department-wide issues. Participants are the whole cross-functional team plus a facilitator.

Structured experiments. Anyone can run one. A structured experiment has an objective (what we want to learn), a hypothesis with success criteria, a definition of who is involved and what changes, a timeframe and an owner. It is monitored, analysed with its context, and concluded in writing. An experiment that disproves its hypothesis is still a success; only one that proves nothing has failed, and even then we record why. Be mindful of running experiments that interfere with each other or with time-critical work.

Hit squads. When a ways-of-working problem crosses team boundaries, a short-lived cross-team group can form to solve it. The problem must be well defined, agreed as a priority by leadership and the people involved, and have a named owner and a sponsor from the department's leadership. Hit squads experiment, converge on a solution, document what they did, and disband.

Communities of practice. Groups with a shared discipline or interest, whether a core competency such as testing or design or an emerging one such as security testing or estimation, meet to share knowledge and raise each other's mastery.

Hackathons. Time set aside to experiment, learn and build something valuable together. See Hackathons.

Root cause analysis. Plan, do, check, act. Five whys. Root cause categories on every resolved support issue, so that the pattern across incidents is visible, not just the incident in front of us.

What it gets us

Better products, less waste, lower cost, faster delivery and a department that people enjoy working in. None of those arrive in one leap.