Microsoft XIT Drum-Buffer-Rope Implementation
Case: A specific real-world TOC implementation that practitioners across the field repeatedly cite.
Microsoft’s XIT Sustained Engineering team, which maintained more than 80 internal applications from Hyderabad, applied the Five Focusing Steps and Drum-Buffer-Rope to its change-request queue between late 2004 and late 2005, without changing how its engineers designed, coded, or tested software.
David J. Anderson and Dragos Dumitriu reported the case at the TOCICO World Conference in November 2005. A team rated the worst in its business unit went from 17 completed change requests a quarter to 56, cut typical lead time from five months to about two weeks, and lifted due-date performance from almost zero to above 90 percent. Most of that gain came from three management changes: a buffer, an end to up-front estimating, and moving one tester into development. Added headcount came last. The case is cited as evidence that DBR, not only Critical Chain, applies to knowledge work, and the Kanban method later retold it as one of its own antecedents.
Context
XIT Sustained Engineering handled small change requests, mostly bug fixes under 120 hours of development, for applications used inside Microsoft. In July 2004 development and testing moved to a vendor team in Hyderabad, India, working under the Team Software Process and Personal Software Process (TSP/PSP). The team had three developers and three testers. Four internal customer groups each sent requests through a product manager who set priorities and funded the work.
Demand ran at about one request a day, roughly 85 a quarter, while the team could finish about 20. Between July and October 2004 it completed 17. The backlog passed 80 and grew by up to 10 a month, and requests typically took at least five months. Dumitriu took over as program manager in September 2004 and asked Anderson, whose Agile Management for Software Engineering (2003) applied TOC to software, for help.
The job description management had written for the post asked for database and reporting skills, on the theory that the team lacked data. Anderson read that as the trap Goldratt describes in The Haystack Syndrome: drowning in data while missing the information.
What Was Tried
Control release with a buffer. The team replaced the open-ended backlog commitment with a short queue of approved requests in front of development, typically about seven requests or roughly seven days of work. A request didn’t get a delivery date until it entered a slot. The rope was the total admitted: about 12 requests, seven queued and five in progress. The authors note that choking release this way also exposes where the slack sits. At this stage they still describe the constraint as unidentified, somewhere inside the black box of development and test.
Subordinate estimating. Every new request had required a “rough order of magnitude” (ROM) estimate from one developer and one tester within 48 hours, about a full person-day per request. Estimating consumed 33 to 40 percent of capacity, and only half of the estimated requests were ever built. Estimating stopped.
Historical data showed a typical request took five development days, with a range of one to 15, so every request was treated as equal in cost. Anything that turned out larger than 15 days was diverted as a project once a developer spotted it. Monthly reprioritization of the whole backlog ended too. When a slot opened, the four customers negotiated by email or phone which request should be delivered within the next 25 business days, with slots shared in proportion to each group’s funding.
Change the accounting. Customers had treated their budget as an account to draw down request by request, which is why every request needed a cost estimate. The vendor contract was in fact a fixed 12-month commitment. Once customers accepted that operating expense was fixed, the Throughput Accounting reading followed: the question became which request matters most, not what each one costs.
Identify by observation, then reallocate. Historical data suggested two developers per tester, yet the team ran one to one and the testers appeared fully busy. With release choked and estimating gone, test should have had slack. Dumitriu checked by spending two weeks with the team in India, watching. Test did have slack, so development became the designated capacity-constrained resource (CCR), and one tester moved to development, shifting the ratio from three and three to four and two. A second queue of around eight then protected test, because non-code changes went straight to testers and could have moved the constraint there.
Elevate last. Only in the first quarter of fiscal 2006, after the other steps had run, did Microsoft add two people, one developer and one tester.
The flowchart below shows the process after the changes, with the drum and both queues.
flowchart LR accTitle: XIT Sustained Engineering request flow after the DBR changes accDescr: Change requests from four customer product managers wait in a backlog. A request enters the development buffer of about seven committed requests only when a slot opens. Developers, the capacity-constrained resource, pull from that buffer and pass finished work to a ready-for-test buffer of about eight, which also receives non-code changes directly. Testers pull from it and release work to user acceptance testing, with a 25-business-day delivery promise. PM["Four customer product managers"] --> BL["Backlog, no dates promised"] BL -->|"slot opens"| DB["Development buffer: about 7 committed requests"] DB --> DEV["Developers: the constraint"] DEV --> TB["Ready-for-test buffer: about 8"] NC["Non-code changes"] --> TB TB --> TEST["Testers: slack capacity"] TEST --> UAT["User acceptance testing within 25 business days"]
What Worked
The paper’s numbers are clear about sequence. Quarterly deliveries rose from 17 to 44 across fiscal 2005 with no new money and no new people, which the authors report as a 155 percent throughput gain. Deliveries reached 56 in the next quarter, after the two added hires. Cost per request fell from about $7,500 to $2,900, because the same fixed spend now covered more work. Committed requests reached user acceptance testing within 25 business days, typically 12 to 14, with due-date performance above 90 percent. The backlog fell from more than 80 to under 10, and the paper reports the team was no longer seen as a constraint on the organization.
“Throughput” in the paper counts completed change requests. An internal IT group generates no sales, so this is a goal-unit stand-in. It isn’t throughput in the Throughput Accounting sense of money generated through sales. The distinction matters when the case is used to argue for a business result.
The engineering method never changed. TSP/PSP stayed in place, and work was still estimated, but only by the person about to do it, when the analysis would be used at once. The authors’ conclusion is that much of what limited the engineers had to do with how work was planned, queued, and scheduled rather than how it was engineered.
What Did Not
For a case cited this often, the evidence is thin. It covers one team of six to eight people over about five quarters, and the implementers wrote the report. The paper doesn’t report an independent audit or any data beyond the first quarter of fiscal 2006.
The DBR is partial. Nothing in the paper resembles Buffer Management: no buffer zones, no penetration tracking, and no color signal telling anyone when to expedite. Urgent “Severity 1” requests still jumped the queue and put existing work on hold. The paper reports above-90-percent due-date performance despite those interruptions, but the design had no protection against them beyond putting other work on hold.
Slot allocation also rested on goodwill. The four customers shared openings “amicably,” in the paper’s word, tracking delivered requests against funded capacity. That works with four groups that trust a now-predictable team. The case doesn’t show how the rule behaves when customers compete hard for scarce slots.
What Practitioners Draw From It
For ToC for Software and DevOps, XIT shows that the Five Focusing Steps can run in a software organization without the full Thinking Processes or a Critical Chain implementation. The authors make that argument outright. The reusable part is the order. Release control came first and helped expose the constraint, observation confirmed it, policy changes came next, and money came last.
For Subordination and Policy Constraint, the estimation rule is a clean teaching example. Estimating looked like good management and made prioritization and budgeting possible, yet it took up to 40 percent of the constraint’s time, half of it on work that never shipped. The policy, not the developers, was limiting output.
For Drum-Buffer-Rope, XIT shows what survives translation into intangible work. The drum is the developers’ pace. The buffer is a short queue of committed requests. The rope is a cap on total admitted work and a rule that dates are promised only on admission. The second queue in front of test is a direct analogue of protecting against a wandering constraint.
For Flow Metrics for Knowledge Work, the case is a worked reading: lead time, due-date performance, completed requests per quarter, and backlog size, each tracked before and after the change.
Disputed Lessons
Was it DBR or kanban? The 2005 paper describes DBR throughout. Anderson later retold the same case in kanban vocabulary in Kanban (2010), and Kanban University’s case summary now calls it Microsoft’s first Kanban program, with WIP limits in development and test. That summary also describes weekly replenishment meetings, which the 2005 paper doesn’t mention. It says slots were filled ad hoc by email. The mechanism is the same pull logic under either name. For certification purposes, read the 2005 paper as a DBR case and the later accounts as its reinterpretation by the method it helped start.
Is a count of requests a time buffer? In TOC the buffer is time, and DBR’s Constraint Buffer is sized in time. XIT counted requests. Anderson’s paper ties the count to roughly seven days of work, and the count worked as a time proxy only because the team had made requests roughly uniform: one standard cost, a 15-day ceiling, and larger work diverted. Copy the count without that uniformity and it stops measuring time.
Which numbers belong to the case? Some retellings join the 155 percent figure to the 17-to-56 rise, though the 155 percent figure describes 17 to 44 without new staff. Kanban University’s summary cites a 230 percent rise, lead times of 12 days, and 98 percent on-time delivery without naming the measurement window. Quote the window with the number.
Did TOC do the work? The authors say two of the three interventions seemed like common sense and that TOC acted mainly as permission, confirming what Dumitriu already suspected. One reading is that the case proves little about TOC. The stronger reading is that the focusing steps made the common sense defensible to customers and management, and that the buffer, the one change nobody found obvious, is what made the other two safe.
Related Articles
Contrasts with: Agile CCPM — XIT is recurring maintenance flow managed with DBR, not project work managed with critical-chain buffers; the two software applications of TOC answer different scheduling problems.
Contrasts with: Constraint Buffer — XIT's buffer was counted in requests rather than set in time; the count worked as a time proxy only because requests had been made roughly uniform in size.
Implements: Drum-Buffer-Rope (DBR) — XIT is DBR carried into software maintenance: developers are the drum, a short queue of committed requests protects them, and new work is admitted only when a buffer slot opens.
Implements: Five Focusing Steps — The case paper walks the focusing steps explicitly: development designated as the capacity-constrained resource, exploited through a buffer, the rest of the system subordinated by abandoning estimates, and the constraint elevated only after the first three steps had run.
Informs: Flow Metrics for Knowledge Work — The case supplies concrete readings for lead time, due-date performance, backlog, and completed requests per quarter in intangible work.
Supports: Policy Constraint — The estimation rule, monthly reprioritization, and charge-back cost accounting were policies, and removing them released more capacity than any engineering change.
Supports: Subordination — Stopping up-front estimates is the case's central subordination move: an activity that looked like good management was consuming the constrained developers' time.
Supports: ToC for Software and DevOps — XIT is a documented software implementation of the delivery-system pattern, with before-and-after figures for lead time, due-date performance, and completed requests.
Uses: Capacity-Constrained Resource (CCR) — The paper names development as the capacity-constrained resource only after direct observation showed slack in test; the designation drives every later decision.
Uses: Throughput Accounting — The case drops per-request cost accounting once the vendor contract fixes operating expense for the year, so cost per request falls as completed requests rise.
Sources
• Anderson and Dumitriu, “From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft’s IT Department” (TOCICO World Conference, November 2005). The primary case paper: baseline data, the three interventions, the CCR designation, buffer and rope sizes, quarterly productivity tables, and results.
• Anderson, Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (2003). The book that brought Dumitriu to Anderson, applying the focusing steps, DBR, and Throughput Accounting to software work before the XIT case.
• Anderson, Kanban (2010). Anderson’s later retelling of the XIT case in kanban-method vocabulary, the main source for the case’s place in the kanban lineage.
• Kanban University, “Kanban Transforms Microsoft IT Services, Defying Geographic Challenges” (Kanban Case Study Series, 2023). The kanban-method summary of the case, including figures that differ from the 2005 paper’s and its account of weekly replenishment meetings.
• Goldratt, The Haystack Syndrome (1990). The data-versus-information argument the authors used to diagnose the original job description, and the source of the throughput, inventory, and operating expense definitions the case’s accounting change relies on.
• Cox, TOCICO Dictionary (2nd ed., 2012), entries “drum-buffer-rope,” “drum-buffer-rope for services,” “drum,” “rope,” “time buffer,” and “buffer.” The certification-grade vocabulary for reading XIT as DBR for services and for the time-buffer question.