Quantcast
Channel: ReQtest
Viewing all articles
Browse latest Browse all 383

Working efficiently with distributed teams

$
0
0

Join 25,000 subscribers

Don't worry, we will never spam you.

There are different types of distributed teams and they all challenge the team members in their work in different ways. The model describing our work at ReQtest is one called Co-located Part-Time. For us that basically means that we work together in on office most of the time, and actually, we sit in the same room, but not always.

 

This is a model we have tried out for some years now, and we are happy it has worked really well after a few adjustments.

 

We will go through some other methods and types and describe what is specific about them and what challenges each presents;

 

Co-located:

The whole team is working together in the same office all the time. This is a very unusual pattern. It is not very likely that this could be done for a whole team through an entire project.

 

Co-located Part-Time:

As above but with exceptions such as part-time employees, vacations, illness, flexi-time, working from home on a temporary basis, or other commitments and circumstances. This is the method we have chosen here at ReQtest.

 

Overlapping with Distributed Work Hours:

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

 

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.

 

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 but with the same working hours: the team members may be working from different offices, but they have the same office hours.

 

How to lead distributed teams

We had already touched upon this topic, but I 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 do to contribute with to develop the best product ever

 

 

Get to know your enemy

You have to understand your enemies to be able to fight them. One of you 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 have only one backlog, not a “sub backlog” , “sliced backlog”, “backlog part 1 for team 2” or other creative home made solutions. You should have only one backlog, known and understood by all members in all your teams.
  • Spend time making sure the backlog is not unrealistic, it has to make sense. This means that you have to say “no” 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 change, so don’t spent 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. We use the powerful requirements module in ReQtest to support us in this important work. ReQtest helps us to keep our backlog tidy. Also we can sort our requirements in any way we choose to get exactly the right information needed so that we can make the right decision based on updated data. We share the information 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 knowledge of the team, involve them in the grooming.

 

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

The post Working efficiently with distributed teams appeared first on ReQtest.


Viewing all articles
Browse latest Browse all 383

Latest Images

Trending Articles



Latest Images