Improve Collaboratively (Evolve Experimentally) is the sixth and final core practice of Anderson's kanban-method: using models, the scientific method, and shared understanding to drive incremental improvement of the workflow system through experiments rather than top-down mandates or revolutionary change.
The Full Name and Its Significance
The practice is sometimes stated in full as "Improve collaboratively, evolve experimentally (using models and the scientific method)." The second clause is load-bearing: improvement is not brainstorming or opinion-sharing, but hypothesis-driven experimentation with the workflow system. A team identifies a problem (e.g., items are aging in the Review column), forms a hypothesis (e.g., the review stage lacks clear entry criteria), makes a change (explicitly states entry criteria), and observes the effect on lead time and flow.
This connects directly to w-edwards-deming's Plan-Do-Study-Act cycle. Anderson positioned the Kanban Method as inheriting Deming's quality management epistemology: the process is a system that can be studied and improved through disciplined observation and experiment.
Models as Improvement Tools
Anderson's phrase "using models" refers to the body of frameworks that the Kanban community developed as diagnostic and design aids:
Using models means teams are not improvising improvements; they have frameworks that encode accumulated knowledge about what works and why.
Collaborative vs. Imposed Improvement
The "collaboratively" qualifier is also significant. Anderson contrasted collaborative improvement with two failure modes:
1. Top-down mandated change. A manager decides what the process should look like and imposes it. This may work in the short term but doesn't build team ownership of the process, and change-management problems are likely. 2. Individual heroism. A single champion drives improvement through personal effort. This is fragile and does not create organizational capability.
Collaborative improvement means the whole team owns the workflow system and participates in its evolution. The implement-feedback-loops cadences — particularly the retrospective-like review meetings — create structured opportunities for this collaborative engagement.
Relationship to Kaizen
Toyota's kaizen philosophy — continuous, incremental improvement involving all workers — is a clear ancestor. taiichi-ohno built kaizen into TPS as an institutional practice: production workers were expected not just to execute the process but to improve it. Anderson's collaborative improvement practice adapts this for knowledge work: knowledge workers are expected to be active agents in evolving their workflow, not passive executors of a process designed by management.
The difference from kaizen is scale and formalization: Toyota's kaizen system includes extensive institutional infrastructure (quality circles, improvement boards, structured suggestion systems). Anderson's formulation is simpler and designed to emerge naturally from the feedback loops and visualization practices already in place.
Evolutionary Change as Context
Improve Collaboratively is the operational expression of the evolutionary-change principle. The principle says the organization commits to incremental change; this practice specifies the mechanism: regular, collaborative, model-informed experimentation. Together they articulate Anderson's core claim against disruptive transformation methodologies: you don't need to blow up the system to improve it, and blowing it up is riskier than you think.