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.

Theory of Constraints

Eliyahu Goldratt's Theory of Constraints is the most useful single lens for thinking about process improvement on a Stream Team. The core claim: there is a bottleneck in every process, and improving anything other than the bottleneck does not improve overall throughput.

When a team-of-functions works in isolation (research hands off to design, design hands off to development, development hands off to QA) every function looks busy, but the work itself sits idle in queues between them. The bottleneck moves around depending on which function is currently overloaded. Each function locally optimises and the system globally underperforms.

Five steps Goldratt prescribes for any process improvement:

Identify the constraint. Use value stream mapping to see where work piles up.
Exploit the constraint. Get every drop of throughput from the constraint without yet adding capacity. Remove non-essential work from the bottleneck step.
Subordinate everything else to the constraint. Other functions deliberately work to the pace of the bottleneck rather than producing inventory that piles up in front of it.
Elevate the constraint. Once exploitation has been maxed out, add capacity (people, automation, tooling) to the bottleneck.
Repeat. The constraint will move once you've improved it; restart from step 1.

Most "productivity" interventions in product organisations target whichever function is loudest about being overworked, not the actual bottleneck. Goldratt's prescription is to identify the constraint that's limiting throughput, then improve that one before moving on.

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.