Using Agile to Build a Distributed Development Team
Joost Mulders and Andriy Korpan presented their experiences with a distributed agile team at the XP Days Benelux 2013 conference. They showed how they integrated a near shore development team from Ukraine in a Dutch product development organization using agile practices, and talked about the do’s and don’ts of distributed agile.
Mproof is an agile software vendor of IT Service Management solutions for the midmarket and managed service providers. They needed to expand to keep up with the competition, and decided to start working with the Ukrainian company Symphony Solutions. Since the waterfall approach that they initially took wasn’t successful they decided to move to agile. Joost and Andriy talked about the five essential things in distributed agile: Culture, communication, commitment, connection, and capacity management.
Joost stated that “you cannot build a culture, you can only grow culture”. For instance, in Ukraine you have differences in the working environment between men and women. This was addressed by having a woman on the Dutch side of the team, and supporting a woman on the Ukrainian side in taking the scrum master role. Another example was that they nurtured a change to bring juniors and seniors on an equal level by maintaining a high junior vs senior ration in their teams, and making clear that every person and their opinions count.
They found out that having conference calls without video didn’t engage the participants, so they decided to use video with all regular meetings, code reviews and pair programming. Also they arranged for people to meet face to face, where initially the team members travelled instead of the project managers. Later the complete teams travelled and took time to get to know each other. Travelling is now tailored to the needs and possibilities of the team members, e.g. taking into account people who prefer not to travel due to taking care of their children. Andriy explained that “communication between people working remotely significantly changes when you have had the opportunity to meet each other in person”.
With a distributed team it can be more difficult to have all team members involved and committed in the team. Commitment was improved by making sure that there was no preference treatment for the Dutch team members, and by having a scrum master from Ukraine. Teams met face to face regularly, and team members from both locations participated as much as possible in the general company events.
You have to find other ways to facilitate connection in the team when you don’t have a shared coffee machine or lunches where team members have their conversations. The companies stimulated the use of social media to communicate, both for work and private. Also socializing events were organized, like an on-line soccer tournament. “Allow the team to have fun while communicating and stimulate this so that they can enjoy working together” said Andriy.
Initially the near shore team was treated as a pool with resources, capacity was requested, and feedback was not given directly but through the Ukrainian CEO. When this didn’t work out as expected, they decided to change their management approach. Team members on the Dutch side got involved in the recruitment of Ukrainian team members, direct input was given for evaluations and they introduced reviews to stimulate open feedback between people from the Dutch and Ukrainian side of the team.
Building a distributed development team takes time and commitment from the organization, and you need to invest money and effort. The implementation of a distributed team can be done in an agile way, learning and improving as you go along.
Steven Ihde,Karan Parikh Mar 29, 2015