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:
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:
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:
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:
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.
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
What else… your experiences…just add them by adding a comment.
We make a distinction between software and hardware:
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
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:
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:
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:
The physical set up I used:
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.