2004 年 7 月，微软 IT 部门内部挂出一个职位。缺项目经理的小组叫 XIT 持续维护组，按后来两位当事人的说法，它被看作所在业务单元里最差的一个。招聘要求写着：会 SQL Server，会 Project Server。想找的是一个能把报表做得更细的人。管理层眼里的毛病是：「数据不够」。
没几个人来应聘。
这个组维护着 80 多个内部应用，接的是小改动，多半是修 bug。新需求差不多每个工作日来一个。开发和测试这时刚转到印度海得拉巴，人员由外包商提供。三名开发、三名测试，从 7 月到 10 月这个季度只做完 17 个。一个需求通常至少要等五个月，按期交付的几乎没有。
9 月，德拉戈什·杜米特留接下了这个位子。一个月后，他去美国质量学会西雅图分会听微软同事大卫·安德森讲课，散场后请他帮忙。两人 2005 年的会议论文，记下了后来的事。
有两个习惯在把这个组拖垮。每个新需求都得在 48 小时内给出粗估，这意味着一名开发、一名测试各花大约半天去读代码。估算最多吃掉四成产能，可估过的需求里，最后真做了的只有一半左右。每个月，四个客户组还要开一次会，把 80 多个积压需求从头排一遍优先级，其中大多数几个月都不会有人碰。
杜米特留把两样都停了。接单时为排期和预算做的粗估取消了，开发真要动手时才估。开发前面只留一小段已批准的需求队列，空位数目固定。一个需求排进了空位，才给交付日期。空出一个位子，客户们发邮件或打电话商量由哪个需求补上。他还去印度看了这个组两个星期，发现测试有空闲，于是请外包商把一名测试调去做开发。
还是这六个人，一年之内，每季度完成的需求从 17 个涨到 44 个。又招了两个人之后，到了 56 个。这时开发环节的上限约为十二个：七个排队、五个在做；测试前面另有一个最多约八个的队列。承诺的需求在 25 个工作日内交给用户验收，通常是 12 到 14 个工作日，九成以上按期。80 多个的积压降到不到十个。按两位作者的计算，每个需求的成本从约 7,500 美元降到约 2,900 美元。
设计、写代码、测试的做法都没变。用两位作者的话说，拖住工程师的东西，很多「和工程方法无关，而在于工作怎么管理、怎么计划、怎么排期、怎么排队」。