Distributed Agile Project Teams

Nicole Belilos and I gave a session called “My Buddy Is Over The Ocean” on the XP Days Benelux 2010. We had some good feedback on our session.

As we don’t like presentations with lots of text, the slides of the session don’t contain much information. Therefore, we wrote this short summary to share our experiences. If have questions or remarks please contact us, we will always respond!

Distributed Approaches
There are several distributed approaches possible. For example:

  • Most of the team members are located in one site, and one or maximum two individuals work from another location;
  • The team is completely distributed, with all team members working from different locations;
  • The team members work from two locations, for example Netherlands and India.

Why work in distributed teams?
When you read books about agile software development, all books explain why it is important to work co-located. So why then would anyone choose not to work co-located?

There are several reason to work distributed:

  • Expansion. When it is hard to find qualified employees in your local country, it could be argument to start working distributed. For example, every year millions Chinese students graduate from university. Therefore, it is relative easy to find well qualified employees over there;
  • Historical. More and more organisations are merging to combine their powers. As a result, these companies end up with employees working from different sites;
  • Support. When you need to support multinationals like Shell, Philips, etc. you need to have support 24/7. When you have multiple sites across the globe, it is easier to give 24/7 support, without need for one site to work 24 hours a day.

Distributed. Yes, but…
Suppose you have been working in a distributed team and you have finished the first couple of iterations. Chances are that you have had the following thoughts:

  • They never say what they really think;
  • There are always so negative;
  • What is this English they speak?;
  • Oh no, the Internet connection is down again;
  • We never get what we asked for;
  • They really don’t understand what is working with such a small bandwidth;
  • They don’t treat us a equal;
  • I have to work in the middle of the night.

In our session we gave our experiences with the above problems and also some tips.

Building a Team
We believe building software starts with building a good team. This is the same for co-located as well as for distributed teams. Building good software with seven individuals on your team is a problem, whether they are co-located or not. True team work is the basis for good software.

However, building a true team in a distributed environment is difficult. There are several challenges you have to face.

Distributed teams members must travel! When you are able to meet each other frequently, you will be able to build a better team. Even if it is possible to build a team via Skype, the best thing is to see each other in real life.

Although travelling is important, you can’t expect people to fly constantly between sites. Travelling costs a lot of energy, especially when it is across multiple time zones. Also, most people don’t like to be away from their family or private life for longer periods of time.

When you build a new team, try to co-locate all the team members for several weeks and have them work together. The primarily goal should not be to transfer knowledge, but to get to know each other. When new team members join an existing team, the same approach can be used to quickly integrate those new members.

Time Zones
The greater the number of time zones involved, the more difficult it gets. How do you plan a meeting when you have people working in the USA, Europe and India? It is almost impossible to plan a meeting during everyone’s regular office hours.

A common solution is to share the pain. Plan the meetings at different times, so that one day the USA people must get up early and India should stay in late, and the other day it’s the other way around.

When you have an office in Norway and India, you will notice that the overlapping time slots are always filled with meetings. Therefore, it is important to always plan local meetings around those shared time slots.

There is no real solution for working with multiple time zones. But make sure it is not always the same people who have to stay in late or come in early.

Cultural Differences
There are thousands of books on cultural differences. It is a fact that many cultural differences exist, not only between different countries, but also within countries and even within companies! As a rule of thumb, accept cultural differences, respect each other and enjoy the differences!

Unfortunately or fortunately :), it is not possible to develop software without communication. There are several meetings that are part, in some form, of every agile method:

  • Stand-up, a short informal meeting to inform each other in the team;
  • Planning, a meeting with the team to plan a new iteration or user stories;
  • Demo, demonstrate the software with the (proxy) customer to generate new input for the next iterations;
  • Retrospective, a meeting to evaluate the last iteration or to discuss certain issues in the team;

Is it just a matter of switching on a web cam?

Language Barrier
In most projects the common language is English. However, there are a  lot of different English accents…You probably are able to understand the English your colleague speaks. However, is someone from the other side of the world also able to understand your English, with your local Russian/Indian/Dutch/French/German/Kenyan accent?

When you use phone or software to communicate, be aware that it could be even more difficult to understand your English.

Meeting Guidelines
While all meetings benefit from good facilitation, distributed meetings need it even more. Make sure you have clear meeting rules. Below is a good example of a set of meeting guidelines.

  • Phone Conferences
    • Allow time for connecting;
    • Strict time boxed and facilitated;
    • Use a good phone and head sets;
    • Let everyone announce himself;
    •  Start with 5 minute chitchat;
    •  Announce your name before you speak;
    •  Take turns when speaking. Don’t interrupt a speaker;
    •  Listen and don’t work on other things at the same time;
  •  Video conferences
    • Allow time for setting up;
    •  Have a strict agenda;
    •  Use good web cams and audio;
    •  Spend 5 minutes to actively ‘see’ each other;
    •  Point the web cam to the person who is talking;
    •  Two rooms: have a facilitator in each room;
    •  One room and x remote people: Have a ‘web cam buddy’ in the main room;

Stand-up & Planning Meeting
The Daily Stand-up and the Planning Meeting have a lot in common. Make sure you have a good web cam and a good microphone. Make sure everyone is visible on the web cam. Try to always use the web cam; receiving visual feedback is very important. Does everyone understand what you are saying, is everyone paying attention and/ or are they making notes during the meeting? Is a planning meeting without making notes possible…

When you have a planning meeting it is advisable to have a separate machine to share the desktop, documents, tools, etc. Make sure you have one dedicated machine for the communication tools and another machine for the project information.

A site that could be useful is http://www.planningpoker.com/, especially when you have all team members working from different locations.

Demo software
The meeting to demo the software is a challenge. This depends on the number of teams in the project and the number of distributed locations.

When there is just one team working on the project, and this team is located in just two locations, the demo is relatively easy. Make sure the customer knows you are working distributed and is able to speak English. When the every team member is located at another site, the demo meeting will be more challenging. How do you share your desktop with all team members and the customer? Are you able to use web cams with multiple locations?

When you have multiple teams working on a project, how do you demonstrate the software to all teams and customers? How do you facilitate discussion? How can everyone hear the people who are together in one room? You could use a wireless microphone. Then make sure only the team member or customer holding the microphone is allowed to speak.

When you want different team members to demonstrate parts of the software, you have to switch the presenter mode regular. How do you prevent this from becoming a bottleneck or annoying part of the meeting?

There are a lot of issues that could occur during this meeting. Make sure you prepare it well, that includes the software and hardware for communication. Additionally, you should have a good chairman or facilitator for this meeting.

Make sure the primary goal of the meeting is still there. Demonstrate (potentially) shippable software and discuss the software to generate insights for the new iterations.

If you think the demonstration meeting is hard, the retrospective is even harder! We believe a good retrospective is all about doing things together and about communication. 55% of communication is done by body language. As a facilitator it is important to be able to observe the people who attend the retrospective. This is very hard to via a web cam.

A retrospective should be very interactive if possible. But how are you going to have an interactive retrospective when the team is distributed? You find a nice example in this blog.

The distributed retrospective is a real challenge, but when you, as a facilitator, prepare it well, it is still possible.

Tools could be a great help or a burden when you use the wrong tools. Additionally, tools won’t solve any problem in the process.

In this section we share some of our experiences with tools. If you know some extra tools, just add them by entering a comment.

Infrastructure & Development Tools

  • CVS versus VSS, we used Microsoft Visual Source Safe 6.0 in the begin to store our documents. VSS is not build to be used in a relative slow network, make sure you use a source control system that is build or at least optimized to be used in a distributed environment. Take a look at the tools that are used by open source projects, they often use tooling that is build to work in distributed projects;
  • Sharepoint, use an Intranet system or content management system to maintain documents;
  • Web Enabled Bug Tracking System, using a fat client could not be a good idea when you a relative slow network;
  • Remote Desktop, take over a system in another location with RDP or for example VNC to only transfer screen information and not all data;
  • Citrix, all your applications in your own virtual desktop environment.

What else… your experiences…just add them by adding a comment.

Communication Tools
We make a distinction between software and hardware:

  • Software
  • Hardware
    • Conference phone, these phones are optimized to be used in hands-free mode;
    • web cam (HD and Wide Angle), don’t save money on this… it is important to see all people in a meeting and to be able to see if they are happy or anger;
    • Headsets, it could happen you have to wear them for a few hours… make sure they are comfortable;
    • Wireless microphone for large meetings, to be able for everyone to join the discussion;
    • Dedicated communication corner in team room, a team should be able set up a meeting in a few meetings. When they have to walk to another room, it is to much effort and the team will not meet to discuss a topic;
    • Meeting rooms with fixed communication corner, it should be possible to meet easily with people from different teams or with the product owner and people from another site;

Planning & Tracking Tools
The number of planning and tracking tools is growing every year. A classic Scrum board that doesn’t use a network cable should always prefer above any software tool if possible.
Possible tools are:

Do you need to bring back your buddy? No really….. if possible yes. If is not possible,
you should really invest in the team and make sure you use the most efficient tools for
your organisation.

Working in or with a distributed team is not easy. However, it is possible with hard

Distributed retro

One of the most important steps of an agile process is the retrospective. It is a moment in time to evaluate the iteration, quarter, release or whatever the team would like to evaluate. Esther Derby and Diana Larsen wrote a great book about agile retrospectives. If you would like to organize a retro or are looking for a different approach, you should really read this book!

My intention is not discuss the book in this blog. However, I need to give you some information from the book to understand my problem.

A retro has different stages. Roughly:

  • Introduction, why are we here, what is the goal of the retro, what is the agenda;
  • Collect the data, facts, emotions, events, (un)completed user stories, etc. Make sure everyone has the same data;
  • Analyse the data, why did al those events happen?
  • Identify actionable items, what could the team do to improve or add used practice to there already existing process;
  • Close the retro, evaluate the retro and explicit close the retro. 

For every stage Esther and Diana describe activities you could use. They describe many great activities in the book. Some the activities are already know to everyone, and some are refreshing. For example:

  • Check-in, an activity that could be used during the introduction. Ask every person attending the retro to answer a simple question in maximum five words. The question could be for example: “what it one thing that’s on your mind about this topic that we are going to discuss?”. Goal is to make sure everyone is in the retro and focussed on the retro;
  • Return on time invested (ROTI), an activity to generate feedback about the retro process itself and measure how the attendees experienced the retro. Draw a line on white board with five marks, starting with lost principle (no benefit received from time invested) ending with high return (received benefit greater than time invested). Ask every team member to give their ROTI of the retro and discuss why the ROTI is as it is. Find out how the retro could be improved.
Back to my situation. I had to facilitate a retro about Q1 of 2010 with a development team. The idea was to look back on several iterations (one iteration is one month) and learn from the all things that happened. There were some team changes in January and the team had to find a new balance. Furthermore, the team lead had left the team, how did the team cope with this?

Here comes the problem….. the team was not co-located…. Most of the activities described in the book of Esther and Diana assume you have a co located team. There are activities that require teams to write down things on a whiteboard, group index cards, write text on post-its. All those things are hard to do when you have four team members in India and four team members in the Netherlands.

Still, I think a retro should be fun. Therefore, I selected several activities from the book and tried to implement them in a distributed environment. I think it went pretty well, the retro was a success and everybody enjoyed the retro.I will first shortly explain the activities, and secondly how I implemented them in a distributed environment.

I selected the following activities:

  • Check-in, already described above.
  • Time line, create a time line of the period that is discussed in the review. Ask the team members to add events, emotions, etc. that they experienced during the period.
  • Like to Like, team members take turns in judging which events of the period best fits with their quality cards. As the cards are evaluated team members learn about each other perspectives on the same events. Quality cards are cards with words like, Fun, On-Time, Cool, Awesome, etc. For the detailed explanation you really need to read the book.

The physical set up I used:

  • Two meeting rooms, one in the Netherlands and one in India;
  • Skype, and both sides a high quality webcam;
  • Interactive Whiteboard with screen sharing, By using screen sharing the Indian team members could follow everything that was written or published on the board.
The check-in was relative easy, I asked all team members: “How would you describe Q1 in one or two words?”. I wrote the answers on the whiteboard to make sure everyone could read them and understand them. This activity is relative easy to do with a not co-located team.

The time line activity is harder to do with a distributed team. Ester and Diana describe in their book, that team members should use stick notes, or just a marker to write their events on a whiteboard. People should discuss in small groups, two or three people. I solved this problem by preparing a digital slide on the interactive whiteboard. I draw a time line that covered Q1. I asked people just to call out events, emotions, user stories completed, etc during Q1. I wrote the items on the whiteboard and trigger the team members to come up with new items. The problem is that you don’t have the small groups, and that people could be afraid to say something in a large group. However, everyone felt safe and comfortable to speak. In my opinion everyone actively participated in this activity.
The major challenge was applying the activity “like-to-like” in a distributed team. The activity involves playing quality cards, people need to quickly play their event card, etc. After the time line activity I asked all team members to write down things that we need to stop doing, continue doing or try. The input for most of the team members came from the time line activity. The team member used paper cards to write down their things. I created a digital quality cards (png files) and a small HTML page. The page uses a java script to display a random picture from a specific folder. During the retro I displayed the HTML page on the laptop that was connected to the digital whiteboard, team members in the Netherlands and India could see the page. As facilitator I opened the page to display the first quality card (By refreshing the page a new card was displayed), all team members could see the quality card. By using the HTML page, I was able to show a quality card to all distributed team members at the same time. We used the webcam to find out which team member played his card last, that card is removed from the game.

The action to identify improvements was also done by using the whiteboard. I wrote down the things I heard during the like-to-like game and we discussed them in the team.

The closing of the retro was done by using an activity called the perfection game. Relative simply for also distributed team.

Working in a distributed team has challenges. You have limits in the things you could do with team. However, when you are creative and use the right tools you could come close to a retrospective that is as efficient and as much fun as co located team. Be creative and don’t hesitate to experiment! There is always room to improve!

For example, something I would improve next time is explain clearly the activity to make sure everyone understands the activity. Maybe inform the team in front about the activities that are used so they can prepare. When you, as facilitator, organize a retro as described above you will probably see team that is enjoying the retro and appreciates the effort you made.

I have included the materials (digital quality cards, HTML page and the agenda) I created for the retrospective, feel free to use them. I would appreciate with when you send me an email if you use them.

Agile Testing: A Report from the Frontline

The first European Agile Testing conference was organised by Díaz & Hilterscheid In October 2009.

I gave a presentation about Testing and Scrum at the Scrum Gathering 2007 in London. A colleague of my revised the presentation and send in a paper with the title Agile Testing: A Report from the Frontline. The paper was was selected and the colleague of my created this presentation and gave it on the first day of the conference.

This year we have session about Agile Performance Testing, check out the program for more information.
Below is the summary of the presentation of 2009.
In the summer of 2005, a large software development project at Planon had spun out of control. Scrum was introduced to get the project back on track. Currently, eight development teams and one support team work on the Planon software suite.

Testers play an important role in our Scrum process. Typically a team consists of a functional designer, four developers, two testers and a technical writer. The testers act as the team’s quality conscience. They are good communicators and team players. Having them on the teams has contributed greatly to the success of our Agile projects.

During the sprint planning meeting, the testers estimate and plan their tasks. With their functional knowledge, they ask questions to clarify the requirements for the team. Our risk matrix helps them to determine the required test effort and coverage.

During the month-long sprint, testers perform their tasks: testing bug fixes, preparing ET charters or test cases, and setting up and maintaining automated regression tests. We try to prevent “mini-waterfalls”; this requires discipline from every team member.

Setting up and maintaining the test automation framework can become a pitfall when time and effort are not invested.

The test manager is responsible for the test policy and -strategy; he coaches the testers and facilitates the monthly professional circle and test retrospective meetings.

The transition to Agile proves to be hard for some testers. We focus on Agility during recruitment and training.