[googleapps domain=”docs” dir=”present/embed” query=”id=dgbfx6nh_587ffnqhkf5″ width=”410″ height=”342″ /]
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 memberas 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
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:
- 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.
Working in or with a distributed team is not easy. However, it is possible with hard labour!