The Situation

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 ...

Background

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 leaves self-organization to long discussions about "how it should be done." The result of the training was that people were enthusiastic and highly motivated to implement their own ideas within the Scrum framework

With the team thoroughly enthused and ready for action (no surprise with all the sugar in the candy), we set out to run the retrospective. We had observed as members developed a group cohesion over the two days, and we felt that they would be able to address difficult topics effectively. On the other hand, they had never held a retrospective in their three months of Agile development, and the problems which had to be worked through were significant.

We've both worked with Esther Derby and Diana Larsen, and often use material from their book Agile Retrospectives - Making Good Teams Great in our work. Here is the agenda we created for the retrospective and posted prominently on the wall:

• Appreciations
• New information
• Puzzles
• Complaints and recommendations
• Hopes and wishes
• Discussion and prioritization of the puzzles, complaints, and recommendations
• Prioritizing the information
• Working out team agreements for the most vexing problems.

When the group is culturally diverse, we're just a bit more anxious on how appreciations will be received. Every time we ask a group to share what actions they appreciated from other team members, it continues to amaze us how die-hard geeks really share these appreciations for one another. And how they love to hear when their actions have been recognized by others in the team. Appreciations are a terrific icebreaker, often with many shared laughs and memories.

The new information section became a dramatic event, when management decided to announce a large team restructure during the retrospective. What could have become a killer for the retrospective by dropping doubt and fear into the team became a demonstration of how honesty and openness helps build a team. The restructure brought opportunities for additional responsibilities to the team and these were able to be shared and explored by the group in a completely non-threatening way.

Our facilitation work started in earnest when we asked what events were not understood by the team members. Puzzles are not necessarily negative. This way we balanced the team's eagerness to become critical with the process while gently moving complaints to the next agenda item. Here we asked them to balance every complaints with a recommendation. All in all the team collected some 35 puzzles and complaints -- without a single Indian or American finger pointing at a colleague.

The Hopes and wishes activity is not only a conclusion of the data-collection portion of the agenda, it also starts the thinking about priorities - what would the people in the room really wish to change in the process?

We captured all of these data points on sticky notes, and had them posted on the wall in little time (Figure 2). To quickly reach consensus on prioritizing the most important items, we used a multi-vote approach, where every person in the room got three votes to distribute over the 35 potential improvements in any way he or she wished. Each vote was represented by a check mark.

To our surprise the team was very much in agreement about the priorities: two items jumped out with more than 10 votes each, than at a distance two more items got four votes. Other votes were scattered over five or six issues. We took the four issues with 10 or four votes as the priority changes for the process, and started to work through them.

During the facilitated discussion that followed, the team was able to design solutions for the issues (Figure 3). In one case team members agreed, after analysis, that the problem was a non-issue because it would not re-occur in the next iteration. The careful build-up of the mood in the room helped the people enormously in their ability to listen to each other, without judgment, and with acceptance of responsibilities in the solution of the problems.

The most significant problems were found in areas that impacted the team's ability to deliver software at the end of a Sprint. Two examples are a process change to agree on a design freeze during a Sprint (with the designers working one Sprint ahead), and practices for conducting the daily conference calls.

We ended up with action items associated with each of the top priority items, and commitment from individuals to ensure that actions were taken.

Impact on Other Team Activities

While the results of the retrospective had some impact on the team and its Scrum implementation, the team-building had, by far, the most positive impact on later activities. With the most significant problems addressed, the team was able to work through the Sprint planning meeting, solving problems around design and work without being hindered by its largest process issues. The positive mood and trust built during the retrospective allowed team members to address hard questions in the Sprint planning meeting. They addressed questions like preferring an alternative ScrumMaster over the obvious candidate, without hesitation and with the right respect for the people involved.

About the Authors

Hubert Smits is a coach and trainer for Rally Software in Boulder, CO. He is working with teams, product managers, project managers and the leaders in the organization during their journey from waterfall and command-and-control to agile, lean, and servant-leadership. Hubert's home is Scrum, which framework he uses as a tool to introduce agile concepts to the various roles in an organization. He teaches and coaches executives in their new role as a servant leader, or teaches product management teams to work with concepts like a product backlog and user stories. With teams and their project leads he uses the Scrum framework to validate the roles in their teams, the practices they use in the projects, and the metrics which help them and the people in their environment to keep an eye on the progress they are making, (and explores what to do if that progress differs from the predicted progress). Hubert works mainly with large, often globally distributed organizations, and visit teams all over the world. Hubert can be reached at [email protected].