Continuous Improvement

Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing.

Jeff Bezos

Processes help teams to adopt best practices without having to discover them for themselves. But every process was created by someone and it is the result of combining the principles of what they were trying to achieve with the context at the time the process was created. The problem is that people focus on the practices and forget the original context that led to the process being the best choice. When the context changes the practices remain. Like tech debt, we need to pay down process debt periodically to ensure that we are following the best practices.

Purpose

Contexts change. Continuous improvement helps teams improve effectiveness, efficiency, and sustainability by revalidating their approach to software development as their context changes. Adopting continuous improvement lets teams adapt to change and deliver high-quality products that exceed user expectations.

Principles and Practices

Effectiveness

Principle	Goal	Practice
The skills of the people building the product are the most important factor in the quality of the product	We need to ensure that the people building the product have the necessary skills and knowledge to do so.	By assessing capability standards we can identify gaps in the team and provide training and coaching to fill those gaps.
There are infinite ways of building software	We need to ensure that we are adopting practices that are the most effective for our context	By defining the process vision we can give teams a framework upon which to compare potential new practices and adopt the ones that move the team closer to the process vision.
Productivity is based on system performance, not individual performance	We need to identify the bottleneck in our process and focus on improving that because improvements made elsewhere will hurt rather than help improve the process.	Using Value Stream Mapping we can identify the bottleneck in our process and focus on improving that area.
You can't manage what you don't measure	We need to make all of the work that the team is doing visible so we can identify the real cause of delays.	By making visible all of the work that a team is doing we can identify bottlenecks and areas for improvement.
People like change, they don't like being changed	We need to let teams decide on the improvements that they need to make	By empowering teams to define how they work they can run meaningful retrospectives to identify issues and implement changes to improve their process.
We don't know how a system will react to changes	We need to make small changes and measure the impact so that we can understand the effect of the change and iterate accordingly.	By implementing Plan-Do-Check-Act cycles we have a methodology for making small changes and measuring the impact.
Products degrade over time	We need to ensure that the product remains fit for purpose as we continuously add features over time.	By implementing practices like product debt audits and design debt audits we can ensure that the product remains easy to use and fit for purpose as we iterate over time.
Technologies evolve	We need to ensure that we are using the best technologies to solve user problems.	By allocating innovation days we can ensure that teams are aware of, and can experiment with, new technologies leading to more effective technology stack evaluations .

Efficiency

Principle	Context	Practice
Repetition reduces productivity	We need to encourage sharing of knowledge across teams to avoid repeating the same mistakes.	By organising internal knowledge sharing sessions and implementing team rotation programs we can ensure that knowledge is shared across the company.
Complexity reduces productivity	We need to ensure that code base for each Stream Team is as simple as possible.	By implementing practices like refactoring we can ensure that the product remains easy to use and fit for purpose as we iterate over time.

Sustainability

Principle	Context	Practice
Public resources degrade over time without continuous effort	We need to ensure that the product codebase and shared elements do not degrade in quality over time.	By assigning teams ownership of their code and design there is an incentive to keep it healthy and avoid the "Tragedy of the Commons" problem.
People leave teams	We need to minimise the amount of knowledge that is lost when a person leaves a team.	By involving multiple people through pairing or teaming, team rotation programs and internal knowledge sharing sessions we can transfer knowledge more effectively across the team to limit knowledge leakage.

Criticisms

Despite its benefits, continuous improvement faces several valid criticisms.

Name	Description	Mitigation
Resistance to Change	Teams may resist changing established processes.	Promote a culture that values adaptability.
Overemphasis on Tools	Focusing too much on tools rather than processes.	Emphasise process and people over tools.
Measurement Fixation	Overreliance on metrics can miss qualitative insights.	Combine quantitative and qualitative feedback.

Anti-patterns

To avoid pitfalls in continuous improvement, be wary of these anti-patterns:

Complacency: Assuming the current state is "good enough" and not seeking further improvement.
Siloed Improvements: Improvements are made in isolation without considering the broader impact.
Jumping to Solutions: Implementing changes without thoroughly understanding the problem.