In July 2004, a job opening went up inside Microsoft’s IT department. The team that needed a program manager was called XIT Sustained Engineering, and it was, by its own managers’ later account, considered the worst in its business unit. The ad asked for skills in SQL Server and Microsoft Project Server. The idea was to find someone who could build better reports. The problem, as management saw it, was “not enough data.”
Few people applied.
The team kept more than 80 internal applications running and handled small change requests, mostly bug fixes. About one new request arrived every working day. Development and testing had just moved to Hyderabad, India, with staff provided by an outside vendor. The three developers and three testers finished 17 in the quarter from July to October. A typical request took at least five months, and almost none arrived when promised.
Dragos Dumitriu took the job in September. A month later he went to hear David Anderson, a Microsoft colleague who wrote about managing software work, speak at the Seattle chapter of the American Society for Quality, and asked for his help. Their 2005 conference paper tells what happened next.
Two habits were eating the team alive. Every new request had to get a rough estimate within 48 hours, and that meant a developer and a tester each spending about half a day reading code. Estimates took up to 40% of capacity, though only about half the requests estimated were ever built. And every month, four customer groups met to reprioritize the whole backlog, more than 80 requests, most of which nobody would touch for months.
Dumitriu stopped both. The team dropped the up-front estimates used for scheduling and budgeting; a developer estimated a request only when starting on it. In front of the developers it kept a short queue of approved requests, capped at a fixed number of slots. A request got a delivery date only when it got a slot. When a slot opened, the customers settled by email or phone which request should take it. After two weeks watching the team work in India, Dumitriu also saw that testing had slack, so the vendor moved one tester to development.
With the same six people, the team’s output rose from 17 change requests a quarter to 44 within a year. After two more people were hired, it reached 56. By then the cap on development stood at about twelve requests, seven waiting and five in progress, with a separate queue of up to about eight in front of testing. Committed requests now reached user testing within 25 business days, typically 12 to 14. More than 90% arrived on time. The backlog of more than 80 fell to under ten, and the authors put the cost of a change request at about $2,900, down from $7,500.
The way the team designed, coded and tested hadn’t changed. In the authors’ words, much of what held the engineers back was “not related to the method of engineering but to the management, planning, scheduling and queuing of work.”