In this article we describe our work with teams that were spread between the US and India, and with the unavoidable cultural difference. We used a facilitated retrospective to discover the most challenging issues in the process and, just as important, to build a team and increase trust between team members. In later work with the teams, we noticed the immediate positive impacts on the people and the process.
This article is a case study based on an actual engagement and the impacts we observed from effective use of a structured retrospective within an Agile transition plan. (One note, we've deliberately disguised crucial identifying details in this article.) We had been asked to help this geographically dispersed set of teams implement Scrum. In our initial preparations we discovered the structure of the teams and many of their challenges. There were three teams involved, two in India and one in Washington, DC, USA. These teams were split along traditional functional lines, with the developers and testers forming two separate teams in India, and the Product Manager, Architect and design team in Washington, DC.
The most apparent challenges facing the group involved applying agile practices to distributed teams. The teams had attempted to implement Scrum by instituting one month iterations, with production releases following each iteration, and holding daily stand-up meetings. Other Scrum practices were never implemented; for example after completing three iterations they had never held a retrospective. Issues across the groups were being privately attributed to differences in cultural interpretation and behavior, but were never explored in a retrospective. To make matters worse, most team members across the two continents had never met one another.
We advised our client to bring all three teams together for Scrum training, a retrospective, and Sprint planning in a week-long session in India. We learned to be careful for what we asked for; before we knew it we were on a long flight from the U.S.; stepping out at the hot humid airport in India at 4 a.m. Our luggage must have agreed with our opinion about the time, and didn't show up until 24 hours later. But we digress ...
The core of all the coaching and training we undertake lies in the rule "software development is a team sport." To create a team we believe that, if at all possible, we need to bring them together and give everyone a common vocabulary and understanding of the new approach. Then, we follow up with the Nike approach: "Just Do It!" This made up the core of our agenda for five days of work with a group of 25 people.
Our plan for days one and two were to run an Introduction to Scrum training class, which we have used with many teams. On day three we planned half a day for a retrospective with the team, covering the three sprints completed before the training session. This time-box proved somewhat optimistic. The last day was reserved for Sprint Planning, plus any ad-hoc discussions that would be required. All these activities were attended by the whole group, including the product owner, a designer, the architect, and a member of the management team from Washington, DC. It is a simple structure and a very intense exercise at the same time.
The Structured Retrospective
The initial two day training effectively allowed the group to get to know one another (Figure 1). One member of the U.S. contingent brought a suitcase of Halloween candy, which proved to be a great ice-breaker between team members. A more serious aspect to the first two days involved the group reviewing its current practices against the Scrum practices. We often use this approach when teaching, first explaining the basic practices, and then exploring with the group ways that these practices can be appropriately modified to fit different situations. The team found this a relief over its own attempts to do everything by the book. More often than not, that type of rigidity limits creativity in solution design, and