 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.
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
Figure 1:
Face-to-face Retrospective
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.
Figure 2:
Issues on Sticky Notes
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.
Figure 3:
Group-developed Solutions
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
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
Tamara Sulaiman is managing
consultant at Applied Scrum, an
IT consulting organization dedicated to the exploration and understanding of
the implementation of practical applications of Agile and Scrum. At Applied
Scrum, Sulaiman is focused on coaching teams and organizations transitioning to
Agile software development. Sulaiman brings more than 20 years
of experience in management across a spectrum of industries including:
information technology, construction, international development and education
to her consulting expertise. She is a Certified Scrum Trainer (CST) and Project
Management Professional (PMP).
Since
2003, Sulaiman has assisted teams in transitioning to agile methods both as a
hands-on ScrumMaster and as an Agile coach and Scrum trainer. She works with
teams in geographically distributed environments and brings her extensive
international experience into her mentoring and coaching. As a managing
consultant, trainer, agile coach, ScrumMaster, and Project Manager; Sulaiman is
focused on coaching teams to effectively provide value to key stakeholders and
customers through the frequent delivery of software.
Comments () |
 |
|
|
|
Tags:
Click to add your tags...,
|
Agile Journal 
