Working efficiently with distributed teams

There are several ways of organizing distributed teams and they all challenge the team members and their collaboration in different ways.

In this blog post we will describe different ways, also called patterns, of organizing teams, what is specific about them and what challenges each presents;

The model describing our work at ReQtest is a combination of Co-located part-time and Overlapping with distributed work hours. For us that basically mean that most of us work together in on office, actually, we sit in the same room. However, some of  our developers work in other cities. We would like to share some of our experiences with you.

Co-located:

The whole team is working together in the same office all the time. This is a very unusual pattern probably a utopia. It is not very likely that this could be done for a whole team through an entire project. One co-located team is relatively easy to manage as everyone is always around.

Co-located Part-Time:

As above, but with exceptions such as part-time employees, vacation, illness, flexi-time, working temporary from home, or other commitments. This is not very difficult either as you are seeing each other a lot. It is easy to schedule meetings and you can discuss issues and even solve problems over a cup of coffee or have an non scheduled meeting ad hoc.

Overlapping with Distributed Work Hours:

The teams work from different offices and/or cities and some or all of the team members work in a time zone close to the headquarters or equivalent. This means that there are some (but not necessarily all) hours during the day when everyone is able to work together.

This is a bit harder to manage than the co-located team. The pattern requires more planning and different infrastructure should you be able to involve everyone effectively. If there is a “main team” and some smaller ones elsewhere you have to pay extra attention to the smaller teams so that they will not be forgotten. It’s important they feel as valuable as anyone else. Try to meet not only in the head quarters, but once in a while at their location if possible or they will have to do all the travelling. Also, don’t always talk business. Share holiday plans, what you did last weekend and some small talk equally, no matter where you work from. The team spirit is important for work and for fun.

Distributed with no Overlapping Work Hours:

The team works distributed in different time zones with large displacement. There are no overlapping hours.  This means that there are no hours during the day when everyone in the team can to work together. This is a big challenge for everyone involved.

Before taking a step into this direction you need to plan a lot. How do we find and get to know each other, what cultural or language gaps are there, how often can we meet, how do we train people, how do we share goals, plans, data, code, information, who should be involved in what meetings, what about infrastructure, can we expect people in another time zone to attend a meeting in the middle of the night, (would I agree to that)  etc., etc.

Dispersed:

Large variation. Here you will find any number of what we sometimes call “lone workers”. The working hours are not scheduled. There could be a combination of any of the patterns above. A dispersed way of working can also appear time to time. A similar pattern is to work distributed with the same working hours: The team members may be working from different offices, but they have the same office hours.

Our advice here is to set some common rules, to be open, flexible and prepared try things out.

How to lead distributed teams

We had already touched upon this topic, but we will revisit with a couple years of experience more. Read that article here – Working as a test leader in distributed test teams

It is a greater challenge to manage a large project than a small one. The more complex, the harder it is to motivate the team to reach the product goal. The difficulty is to balance between doing too much and doing too little in order to control the work. You should do enough, not more, not less. There is a risk that you will end up doing far too much administration that could lead to increasing costs.

Instead, try this

• build in flexibility in your process – so that you can adapt quickly to changes
• empower your teams – so that they can take full responsibility for quality
• support your team in being self-organizing – so that everyone’s competence and ideas are used for maximum delivery and personal satisfaction
• make sure there is transparency between the teams – so that there is an understanding of what’s going on and what they themselves need to contribute with to develop a high standard product

Get to know your enemy

You have to understand your enemies to be able to fight them. One of your enemies is The Poor Backlog Creep. Of course it is always important to have a well groomed backlog, but if you are working distributed it is even more important.

Here is our list of backlog success factors

• Do your release planning face to face. If you can’t meet each other daily, at least make sure you all do your release planning together. Involve your teams in discussing features to come, estimations, value for the customers, goals on different levels etc. The team will be more effective and committed, and also have so much more fun for the next couple of month (or whatever release periodicity you have) understanding, not only what you are going to create together but also why and for whom.
• Do have only one backlog, not a “sub backlog” , “sliced backlog”, “backlog part 1 for team 2” or other creative homemade solutions. You should have only one backlog, known and understood by all members in all your teams.
• Spend time making sure your backlog is not unrealistic, it has to make sense. This means that you have to say “no” to some features even if they are really cool. This also means that you have to make sure your backlog matches your roadmap and your vision.
• Do not even try to get a complete backlog. Many requirements, priorities and so forth will changes quickly, so don’t spend time trying to get everything right from the beginning.
• Keep all your requirements in a well sorted format that is easy for all team members to access. You could use the requirements module in ReQtest to support this important work. ReQtest will help you to keep your backlog tidy. You can validate, estimate, group, and sort  your requirements in any way you choose to get exactly the right information needed so that you can make the right decision based on updated data. Everything can be shared with the team members. No matter where they are in the world, or what time it is, they can follow the requirements to come.
• Implement backlog grooming into your routines. Use the expertise and experience of the team by involving them in the grooming.
• Communicate.  It is not only the requirements that should be understood and shared. The work progress, changed priorities and blockers that might occur ought to be shared as well. It is very difficult to keep distributed teams on track and committed if there are poor channels of communication. A powerful tool will help a lot. An Agile Board, accessable and used by the members in the teams will help you to keep track, not only what tasks there are to be done, but also the progress, who is working on what, and what is left to do before we are “done”. It should be easy for anybody in the team to pull a task and get started. Any team member should be given the latest information without delays and the possibility to add on new information.

Remember that communication is supposed to work both ways, so find a processes that works for all roles in the team, and do have a Product Owner who is updated, interested and available.

And what are your thoughts and opinions? Let me know in the comments below!