Lean Six Sigma in tech

The first thing an honest value stream map does to a software organisation is embarrassing. A change that takes two days of work takes six weeks to reach a customer, and the gap is queues: waiting for review, waiting for a test environment, waiting for a release window, waiting for an approval from a board that meets on Thursdays. The engineering is not slow. The system around it is.

The second is work in progress. Teams take on more than they can finish because starting is rewarded and finishing is assumed, and every extra item in flight makes every other item slower. This is not an opinion about focus, it is arithmetic: the work in the system divided by the rate of completion is the lead time, so more in progress means longer for everything.

The third is the incident loop. Organisations under delivery pressure ship changes with a failure rate they never measure, then spend the following week recovering, which is the capacity that would have prevented the next one. Failure demand exists in engineering exactly as it does in a service desk, and it compounds faster.

A technology project usually needs no new instrumentation, which is both the opportunity and the trap: the data is abundant and mostly beside the point. Define picks one change type and one path to production. Measure builds a timeline per change from the systems that already exist, and the first output is the split between working time and waiting time.

Analyse looks at the queues in order of size, which is nearly always review, environment availability and release approval rather than the coding itself. It is worth resisting the urge to attack the interesting problem before the large one.

Improve is mostly about batch size and limits: smaller changes, fewer things in flight, an environment that can be had on demand, an approval that is a rule rather than a meeting. Control belongs to the team, not to a reporting layer, because a delivery metric owned by management becomes a target and a target becomes theatre within a quarter.

Design and discovery work is not a process to be stabilised. Building something nobody has built before has irreducible variation, and measuring it as though it were a production line produces padded estimates and defensive engineering. The method belongs to the delivery system around the creative work, not to the creative work itself.

The second limit is the metric that becomes a target. Story points, velocity and even the delivery metrics above are useful as a signal and corrosive as an objective. Measure them for the team, review them with the team, and never put them in an individual performance review.

The third is small numbers again. A team having two incidents a month cannot tell a real improvement from luck for a long time, and the discipline is to say so rather than to claim the win in the quarterly update.

And a point of respect: agile practice, continuous delivery and site reliability engineering already carry most of these ideas, often better adapted to the work. If a team is doing this well under those names, the useful contribution is the measurement rigour and the end to end view, not a rebranding exercise.