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!
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.
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.
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?
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.
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;
- 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.
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.
We make a distinction between software and hardware:
- Office Communicator
- Skype (Free), Skype 5 with multiple video streaming!;
- Mikogo for desktop sharing (Free);
- GotoMeeting (Not for free), on-line meetings;
- Yammer, Twitter for inside a company, share information via an informal way;
- MeetingPlace, on-line meetings;
- 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:
- Excel / Google docs to keep track of progress;
- Jira / Greenhopper plugin;
- Take photo’s of a Scrum board, print them and sitck them to the wall;
- VersionOne/ Rallydev / Scrum works / Mingle / etc.
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
Working in or with a distributed team is not easy. However, it is possible with hard
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.
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 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.
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.