Originally Published by David J. Anderson.
I am often asked by conference attendees whether Kanban can be used with distributed and offshore teams. It seems that those newer to Kanban concepts are fascinated with pictures of whiteboards covered in sticky notes, or walls with index cards pinned to them representing work-in-progress (WIP). There seems to be a common assumption that Kanban started with collocated teams doing Agile software development. While some people can see the benefits of limiting WIP even for offshore or distributed teams, it isn’t obvious how it is achieved.
The question, “How do you do Kanban with a geographically distributed team?” always invokes a wry smile from me, accompanied with the answer, “Just the way we’ve always done it!”
In fact the early examples of kanban systems being used in software development were not done with teams collocated together in a single building doing Agile software development, they were implemented with distributed teams with offshore development and/or testing in India.
The first team to implement a kanban system, in 2004, was part of Microsoft’s IT department. The product and program managers were based in Redmond, Washington and the developers and testers were based in Hyderabad, India. The kanban system was implemented to remove variability introduced by management policies regarding planning and governance. The kanban system also provided a mechanism to visualize potential policy changes (that represented process improvements), one at a time.
The “visualization” I talk of here was not achieved with a physical board covered in sticky notes, but with an abstract drawing of stick figures representing a workflow, a tracking tool that collected data on work items and their state changes, a spreadsheet and some very basic management reporting in tabular format.
The Kanban “signal” was generated using a database trigger from the tracking system and “sent” via email to the program manager.
Meetings were held by telephone and the tracking system was accessed via PC by all attendees to facilitate the discussion.
In other words, an electronic tracking system was used for the very first “virtual kanban system” implementation. Over the years, the words “virtual” and “system” have by-and-large been dropped by the community (in the interests of brevity) and hence, we’ve come to know the technique simply as “Kanban.”
Late in 2006, the second virtual kanban system implementation was started at Corbis, in Seattle, WA. In this case, the team was using a traditional SDLC with separate business analysis, systems analysis, development and testing functions. The testing department was located in Chennai, India. The kanban system was initially implemented using only the Microsoft Team Foundation Server tracking tool. The user interface was based on SQL reporting and Microsoft Excel. Later a custom built visual board application was added to make the system more accessible and usable.
So once again, the initial system, was “virtual.”
Kanban was initially introduced at Corbis for the software maintenance function. The kanban system naturally lent itself to the service delivery nature of maintenance work and it was hoped that such a system would lead to a series of improvements and the adoption of a “kaizen” (or continuous improvement) culture.
While some immediate service delivery benefits were realized, the hoped for culture of continuous improvement was slow to emerge. The immediate line manager for the function decided to implement a physical tracking board and have the team stand in front of it each morning for daily coordination meeting. This action had an immediate effect. Very quickly we saw improvement upon improvement and new spirit of collaborative working emerged.
Introducing a physical board when we were already using an electronic tracking system introduced some challenges. Seattle-based employees who chose to work one or two days a week from home found that they were unable to update the physical board. This became problematic as the board was a vital part of coordinating the team’s work. A scheme was introduced called “Sticky Buddy” where each member of staff had a “buddy” who would proxy for them, if they were out of the office, and move tickets on the physical board when a status change happened electronically. This helped to insure that the physical board was kept in sync with the electronic system.
With the offshore team in Chennai, a test lead, based in Seattle, would insure that the tickets on the physical board accurately represented the state of work-in-progress and that the electronic and physical tracking systems were kept in sync. The offshore team did not implement a physical board but relied on access to the work tracking provided electronically.
Since these early days of Kanban adoption, many teams around the world have implemented Kanban for distributed and offshore teams. Electronic Kanban tools such as Digite’s SwiftKanban have become a vital part of a Kanban implementation. Physical boards are often still used. I have seen clients designate an employee at each geographic location whose job it is to insure that the physical board is kept accurately synchronized with the electronic system.
However, as the months and years pass, I feel that physical boards will gradually be displaced with communal electronic systems. Already we see teams using projection white boards, with touch control capability, or large flat panel displays with touch screens. Such systems are becoming very affordable often priced around $3000 – $4000 US Dollars.
So in summary, Kanban for software development has involved offshore, geographically distributed teams since the beginning. Electronic tools used to create “virtual kanban systems” and visualize the work have been used since the beginning. And teams used ingenuity to insure integrity and coordination of physical systems and electronic tools.
