WIP Limits on Paper at Vertex Pay

The limits are being violated because they are numbers on a board rather than agreements inside a system. KMM fitness criteria at ML2 include explicit policies, WIP limits, flow metrics, feedback loops, and a service delivery approach that the team owns. Vertex has the artifacts and almost none of the supporting conditions.

Three specific gaps explain the behavior. First, policies are implicit: no written definition of ready, done, or what counts as WIP; classes of service were announced verbally, so people cannot apply them consistently. Second, the board belongs to the delivery manager, not the team - standups are status reports and the manager updates the board afterward, which removes the team's reason to pull and limit work. Third, the 90% utilization target actively rewards starting work and punishes finishing, the opposite of a WIP limit's purpose.

I would avoid framing this as discipline. Violations are data about demand, policy clarity, and management pressure. In the workshop I would ask what happens when a limit is reached, who can override it, and what the team should do instead - swarm, escalate, or wait. If the answer is that the manager adds it anyway, the limit is decorative and the coaching work is upward, not downward.

Work with the PMO in its own language and with data, not ideology. The utilization metric and the WIP limits are in direct conflict: 90% individual utilization forces people to hold multiple items, which lengthens queues and increases item age. The 27-day average age and 62% over target are the outcome of that conflict. A useful first step is a simple correlation: per team, plot utilization against average item age and percentage over target for the last six months. If the pattern holds, the PMO has a predictability problem, not a utilization success.

Ask for a bounded experiment rather than a policy change: one team, eight weeks, a lower start rate and temporary relief from the utilization ranking, with measures agreed in advance - item age, throughput, percentage over target, and unplanned work. Offer to report in the monthly dashboard so the PMO is not bypassed. If the PMO refuses even a bounded experiment, escalate through the sponsor with the data; at that point the constraint is structural and cannot be solved at team level.

KMM is useful here: this is an enterprise-level fitness gap, and pretending it is a team coaching issue sets the teams up to fail. The coach's job includes making the structural constraint visible to the person who can change it.

First two weeks: observe two standups and one board walk per team, interview the delivery manager, and pull eight weeks of item timestamps. Then run a 90-minute policy workshop with the team - not about the tool, about agreements: what counts as WIP, when work is pulled, what a blocker is, what happens at the limit, how classes of service are assigned, and what done means. Publish the policies next to the board and version them.

In parallel, coach the delivery manager out of the board-updater role: ask her to ask questions rather than move cards, and agree that the team owns the board. Make blocked items visible with age, because blockers are the fastest route to a conversation with management.

Indicators that the intervention is working: team members move cards and pull work without the manager; policies are visible and cited in standup; the number of limit violations falls because work is finished, not because limits were raised; item age distribution shifts left. I would track the percentage of items exceeding 21 days and the age of blocked items weekly, and explicitly avoid measuring compliance. If the PMO metric remains unchanged, I would expect improvement to plateau, which is itself evidence about where the real constraint sits.