Successful Evolutionary Change For Your Technology Business David J Anderson

Why Most Tech Company Restructures Fail

I watched a team try to implement kanban at a mid-size SaaS company once. They swapped Jira boards, wrote a wiki page, and called it done. Three months later, they were back to Scrum ceremonies and nobody could explain what changed. This happens constantly. Evolutionary change is different from transformation because it does not require permission, budget approvals, or a mandate from above. That is both its advantage and its weakness. David J. Anderson built his framework on the idea that you can change a technology business by making small, observable improvements to workflow rather than restructuring org charts or mandating new ceremonies. He worked inside actual software development environments for years before writing about it. The core insight is straightforward: make work visible, limit work in progress, measure flow, and adjust based on data instead of opinion.

Learning Successful Evolutionary Change For Your Technology Business David J Anderson

The approach comes from his earlier work on kanban for software and then expanded into what he calls evolutionary change management. The key distinction from other methodologies is that it does not require you to stop current operations. You implement changes alongside your existing process and demonstrate value before committing further. This is why it appeals to engineering leaders who have seen enough transformation programs collapse under their own weight. I learned this the hard way when I was managing a platform migration for a fintech client. We had six months to move from an on-premise database to cloud infrastructure. The usual approach would have been to hire a consulting firm, do a big design workshop, and spend four months planning before touching production. Instead we used an evolutionary method. We started by mapping the current state. Not the ideal state. The actual state. Every manual step, every handoff between teams, every ticket that sat in "waiting" for three days because the QA engineer was out sick.

We created a simple service request board tracking the migration tasks. No new tooling, just a shared board visible to everyone. We set a WIP limit on the column where work actually happened, which was surprisingly aggressive at six items per person. Within two weeks, the bottleneck became obvious. Database schema changes were queueing up because only two people had production access. That was the actual constraint, not whatever the architecture review said should be the constraint. This is where the method differs from standard agile transformations. You do not start with a target operating model. You start with the current state as it actually exists, including the workarounds, shadow processes, and informal communication channels that never make it into documentation. Most teams skip this step because it feels slow. It is not slow. It prevents you from optimizing a process that does not match reality. Domain One covers the service catalog and demand management. This is what the business actually offers and how requests flow in. A common mistake here is assuming the service catalog matches what customers are asking for. In my experience, the gap between the documented service catalog and actual demand typically accounts for 40 to 60 percent of rework in mid-size technology organizations.

Domain Two involves the people and organizational structure. This is where most change programs focus and also where most fail. Reorganization without changing flow metrics tends to move bottlenecks around rather than eliminate them. I have seen companies restructure into squads and tribes and immediately return to the old hierarchy because the underlying constraints were never addressed. Domain Three deals with knowledge and information systems. Data architecture, documentation practices, and how technical decisions are recorded and retrieved. This domain is often neglected until it becomes a crisis. I worked with a team that lost three weeks of institutional knowledge when their senior developer left and the design decisions lived only in his head. They had never implemented a knowledge retention process because they considered it administrative overhead. Domain Four is policy and governance. Compliance requirements, approval workflows, and the rules that constrain how work can proceed. These are the hardest to change because they often have regulatory backing or exist outside the technology organization entirely. You can work around them, but you cannot change them through software process improvements alone.

The interplay between these domains matters more than any single domain in isolation. A change in the service catalog (Domain One) affects demand patterns in knowledge management (Domain Three). A policy update (Domain Four) can immediately invalidate months of process optimization in Domain Two. Most teams address one domain at a time and get confused when changes in other domains undermine their progress.

Practical Implementation Steps

The method is iterative. You do not plan the end state, you observe the current state, and you introduce small changes that you measure before deciding whether to continue. Here is how it works in practice. Start with a current state mapping exercise. I recommend spending at least two full working days on this, preferably with the actual team members doing the work, not managers reconstructing it from memory. Use sticky notes or a digital whiteboard. Map every step from request to delivery, including the wait times, handoffs, and decision points. Record actual durations, not estimates. The data from this exercise usually contradicts assumptions made in every prior planning session I have encountered. Once you have the current state mapped, identify the constraint. This is not always the thing that looks like the bottleneck from a distance. In a recent project with an API platform team, the apparent bottleneck was the deployment pipeline. But the current state data showed that deployments themselves averaged 45 minutes with zero failures. The real constraint was the pre-deployment security review, which averaged 11 days because the reviewer was shared across five teams. Moving WIP limits to reflect this changed everything.

After identifying the constraint, design a small experiment. The experiment should target the constraint directly, be completable within two to four weeks, and include a measurable outcome. Do not design an experiment that requires new tools or process changes across multiple teams. If your experiment cannot be contained to one team and one workflow, it is not an experiment. It is a project, and projects have a habit of expanding. Implement the experiment, track the results, and decide whether to adopt, adapt, or abandon. This is the evolution part. You are not proving a hypothesis, you are gathering information. Adoption means the change improved flow metrics without creating problems elsewhere. Adaptation means it helped but needs adjustment. Abandonment means it made things worse or had no measurable effect. All three outcomes are useful data. Repeat. The pace depends on your context, but teams I have worked with typically run experiments every two to four weeks. Faster than that and you do not get reliable data. Slower and you lose momentum and organizational attention.

Common Pitfalls and Where This Method Fails

This approach does not work in every situation. I need to be blunt about that. Evolutionary change requires a certain amount of stability in the underlying business model. If your company is pivoting, being acquired, or operating in a market where the product itself is changing every quarter, process optimization becomes noise. You need strategic clarity before you invest in flow improvements. I saw a team spend six months optimizing their sprint metrics while the product direction shifted three times. The optimization was entirely wasted. Another scenario where this fails is when leadership expects quick results. Evolutionary change is deliberately slow because it prioritizes sustainable improvement over speed. If you need cost reduction in the next quarter, this is not the right method. Process flow improvements typically show measurable results in eight to sixteen weeks for established teams, depending on baseline complexity. The timeline is longer than transformation promises but the outcomes last longer too. Transformation programs often see a regression to old habits within six months of launch because the underlying system was never changed. The biggest mistake teams make is treating this as a documentation exercise. Creating the visual board and setting WIP limits is the easy part. The hard part is maintaining the discipline to actually work within the limits and use the data to guide decisions. I have seen teams set WIP limits and then routinely exceed them anyway because "the work is urgent." This is not a process problem. It is a priority problem. No amount of kanban will fix a team that cannot say no to incoming requests.

There is also a measurement problem that catches experienced teams off guard. Flow metrics require accurate data. If your work items are too large, your data is too coarse to be useful. A work item that sits in "in progress" for three weeks tells you nothing about flow. I recommend breaking items down to a target cycle time of one to two weeks maximum. This requires some discipline during planning, but it is the difference between having data and having excuses. One edge case I encountered recently involves distributed teams across time zones. The standard advice is to maintain a single continuous flow board, but when your team spans three time zones, handoff delays dominate the metrics regardless of process improvements. In that case, I shifted the experimental focus from flow optimization to reducing handoff dependency by reorganizing work into time-zone-aligned delivery clusters. The change was specific to the constraint we identified, not a generic application of the framework. This kind of adaptation is where the method shows its value compared to rigid process implementations.

Measuring Whether It Is Working

Track three metrics consistently: cycle time, throughput, and work in progress. Cycle time is the elapsed time from when work starts to when it delivers. Throughput is the number of items completed per unit of time. WIP is what is currently being worked on. These are simple numbers that require minimal overhead to collect once your board is set up correctly. Expect some resistance from team members who prefer qualitative feedback. "We are busy" is not a metric. "We completed 12 items this week with an average cycle time of 4.2 days" is information you can act on. The transition from opinion-based to data-based decisions is uncomfortable for teams that have operated on instinct, but it reduces conflict because the data speaks for everyone equally. If your numbers are not moving after six to eight experiments, the problem is likely upstream. Either the constraint identification was wrong, or the experiments are too small to create measurable change. At that point, revisit the current state mapping. Something was missed in the initial analysis.

The framework is documented in several of Anderson's publications. His book on kanban for software development covers the technical implementation details, while his work on evolutionary change management addresses the organizational aspects. The foundational materials are available through the kanban university platform and various publications that cover the methodology. Start with the current state mapping. Everything else depends on getting that right.