The belief that Kanban only works with small, co-located teams is a persistent myth that Microsoft’s XIT Sustaining Engineering department helped debunk in dramatic fashion. After successfully introducing Microsoft’s first Kanban program, the Sustaining Engineering team, which handles internal change requests across different time zones, went from having the company’s worst service record to its best despite being geographically disbursed, proving the adaptability and effectiveness of Kanban principles.

The Challenge

To understand the challenges facing the Sustaining Engineering team prior to its use of Kanban, it helps to grasp the complexity of Microsoft’s IT organization. At the time, Microsoft operated as seven distinct business units, each with its own IT function, along with a corporate headquarters unit containing shared services. XIT served corporate shared services, focusing on IT support and applications such as the human resources employee records system and the payroll system managed by Microsoft’s finance unit.

Sustaining Engineering, located in Hyderabad, India, was a small team tasked with maintaining and improving these IT applications outside of major releases and application upgrades. However, they were plagued by problems, including long lead times, poor reliability, and broken promises. This was further exacerbated by a time difference of 13 hours between Microsoft’s Seattle headquarters and Hyderabad.

One of the major challenges faced by the Sustaining Engineering team was its lack of visibility into the American multinational’s high-level business objectives or initiatives. Requests for changes and bug fixes often arrived in isolation, making it difficult to understand their strategic importance. The team was essentially an order-taking service, and the context surrounding these requests was often missing.

Additionally, the team suffered from an excessive backlog, with an average lead time of five months for change requests. This, coupled with the habit of making delivery promises they couldn’t keep, eroded trust with their customers. Moreover, they were bound by certain requirements, including a mandate to use structured software development processes that didn’t always work well in a virtual environment.

Estimation issues were a significant contributor to Sustaining Engineering’s woes. The team was required to calculate each request’s potential return on investment (ROI) before deciding whether to proceed, which took considerable time and effort. This process preempted planned work and delayed delivery.

The Solution

As a first step, the team halted the estimation process and replaced it with service level agreements, hoping the switch would improve delivery outcomes and customer satisfaction. Team management also decided to introduce Kanban as a solution using a strategy that involved several key process changes:

Limiting Work in Progress (WIP): Enforcing WIP limits in development and testing allowed the team to focus on a manageable number of tasks at a time.
Replacing monthly planning: Monthly planning meetings were replaced with weekly replenishment meetings to adapt to changing priorities more effectively.
Manage flow: One goal was to anticipate the maximum anticipated delivery rate between weekly meetings, with another to understand the process as an explicit set of policies.
Streamlining communication: Instead of sending new work requests to Hyderabad for estimation, the team communicated more frequently and directly with stakeholders.

Getting Agreement

But before committing to this new way of working, team managers engaged in good old-fashioned “shuttle diplomacy.” They met with individual stakeholders to explain the proposed changes and clarify that their roles in the organization weren’t being called into question or threatened in any way. This proved successful, with stakeholders agreeing to commit to the changes before holding a big kickoff call.

Kanban began to work! Requests were processed and released to production per each service level agreement. Delivery times for new commitments were met within a promised 25-day window, and the weekly meetings – focused more on urgency and less on ROI – were well received by product managers.

The delivery rate of change requests jumped by a whopping 230%, lead times fell from an average of 5.5 months to a mere 12 days, while on-time performance rose to 98%. Without the flow paradigm and the Kanban approach of limiting WIP, those performance gains wouldn’t have been possible. Kanban enabled incremental changes with low political risk and low resistance to change.

The story of Microsoft’s XIT Sustaining Engineering team shows how a WIP-limited pull system can be successfully designed and managed on a large scale across continents and time zones. The team’s impressive results prove that Kanban’s start-with-what-you-do-now approach to evolutionary change isn’t just for small, co-located teams but that it can be of great use to large multinational firms like Microsoft as well.