Evolutionary Process Improvement

Definition

Design the process by having the team evolve it continuously, not by prescribing it upfront. Hold regular process improvement workshops (weekly or biweekly) where the team reflects on what's working and what hurts, prioritizes real pain points (not theoretical ones), brainstorms multiple options for each, and decides via consensus voting (thumb up/sideways/down, or fist of five). Treat each change as an experiment whose success will be validated in the next workshop. Deliberately manage the rate of change by requiring lightweight process improvement proposals for cross-team changes and sometimes deferring good ideas to the next cycle to avoid change fatigue.

In the Book

The PUST project didn't design its process upfront. Instead, Kniberg ran weekly process improvement workshops where the team gathered to discuss victories and pain points. Initially they tried everything—they'd identify a problem, brainstorm solutions, pick one, and run it. Many ideas worked beautifully. But after a few months, people were confused and frustrated: the process kept changing, and by the time you learned one rule, three other rules had changed. They hadn't failed at implementing changes; they'd succeeded too well at changing everything at once. So they introduced a lightweight change: anyone proposing a cross-team change had to write a one-page proposal naming the problem, who's affected, and what they'd try. At each workshop, they'd discuss multiple change proposals and pick only one or two to implement that cycle. This throttled the rate of change without killing innovation. The key to buy-in was consensus voting: each proposal was discussed, advantages and disadvantages listed, and people voted by thumb or fingers. A change had to reach "sideways" (acceptable to everyone, even if not loved) to pass. This meant people felt heard and wouldn't resist the change because it wasn't imposed.

Why It Matters

This concept shifts power from process designers to the team doing the work. It assumes that people inherently want to improve and are the best judges of what hurts. By grounding changes in real problems (not theory), running small experiments, and using consensus to build ownership, evolutionary improvement avoids the common failure mode of top-down process overhaul: "We implemented Kanban/Agile/[methodology]" meets resistance because the people doing the work didn't design it. The consensus voting is especially powerful—it's slower than decree, but the few extra minutes spent getting to thumbs-up dramatically improves the likelihood of adoption and success. This applies to any organization trying to improve: schools, hospitals, manufacturing, anywhere people resist imposed change but embrace improvements they helped design.