DMAIC, Queues and a Kanban Pilot on the Payments Platform
A payments platform team handles 240 change requests a month across three squads. Lead time from 'ready for development' to production averages 26 days, of which only 3 days are actual work: 11 days are spent waiting for a test environment and 6 days waiting for change approval. The defect escape rate is 4%. The head of engineering has launched a Six Sigma DMAIC project to cut defect escapes to 1%, with a green belt assigned for four months and an executive sponsor who reports progress monthly. Meanwhile, complaints about slow delivery of small enhancements have doubled, and two customers have escalated. A Kanban pilot in one squad reduced its lead time from 24 to 9 days in six weeks by limiting work in progress; however, squad utilisation fell to 70% and the delivery manager objected that 'people look idle and we are paying for capacity we do not use'. The green belt asks you whether to continue.
1. Evaluate whether DMAIC is the right method for this situation.
Read the worked answer
DMAIC is a strong method for reducing defects in a defined, repeatable process with data - but it addresses the wrong constraint here. The dominant problem is flow: lead time is 26 days against 3 days of work, so flow efficiency is about 11%, and the largest waits are a test-environment queue (11 days) and change approval (6 days). Those are queueing and constraint problems, not defect problems. A four-month green-belt project aimed at cutting 4% escapes to 1% risks optimising a secondary measure while customers continue to wait and complaints double - a textbook local optimisation. There is also a measurement risk: if defect escapes fall because fewer risky changes reach production, the improvement may be illusory.
The better first move is value stream mapping to make the waits visible, then Kanban and constraint management to reduce them, which the pilot already demonstrated (24 to 9 days). Keep DMAIC available: once flow is stable, it may be the right tool for the defect sub-problem, or it can be reframed with the problem statement 'reduce test-environment wait time'. As continual improvement lead, I would recommend re-scoping the project rather than cancelling it, and agreeing with the sponsor that the primary outcome is end-to-end lead time.
2. How should the team respond to the delivery manager's objection that 70% utilisation means idle people?
Read the worked answer
The objection confuses utilisation with throughput. Utilisation measures how busy a resource is; what the customer experiences is lead time and delivery rate. Queueing behaviour means that as utilisation approaches 100%, waiting time rises sharply, because there is no capacity to absorb variation in work size, test failures or absences. The squad's drop to 70% is not lost capacity; it is the buffer that allowed lead time to fall by 62%. Little's law makes the relationship concrete: with a fixed amount of work queueing ahead of a stage, the time in the system is driven by the queue, not by how hard people work.
The 26-day lead time also has a cost of delay - abandoned enhancements and escalated customers - which finance can compare against apparent idle capacity. I would respond by measuring flow efficiency, throughput and lead time rather than utilisation, by explicitly protecting capacity for improvement work and unplanned demand, and by showing the delivery manager the queue-time data. If utilisation genuinely needs to rise, the answer is to pull more work only when the constraint has capacity, not to remove the WIP limit.
3. Recommend a measurement set for judging whether expanding the Kanban approach is an improvement.
Read the worked answer
Measure the outcome and the system, not the activity. Core set: end-to-end lead time (median and 85th percentile, with wait time by stage), throughput (items delivered per month, by service class), work in progress, flow efficiency (touch time divided by lead time), change failure rate, mean time to restore, defect escape rate, and customer-facing delay or abandoned enhancements. Segment by service class so that small enhancements are not averaged away by large changes. Add guardrails: squad sustainable pace or overtime, quality of testing, and rework.
Use a baseline from before the pilot and review at 6 and 12 weeks, so seasonal demand and release mix are visible. Avoid story points, test counts, pipeline runs and utilisation as success measures - they reward activity. Present the set on one page, with the improvement hypothesis stated: 'expanding WIP limits to three squads will reduce 85th-percentile lead time by 30% without raising change failure rate above 10%.' That lets the delivery manager and sponsor judge the change on evidence rather than impressions.