Should internationally distributed Teams be avoided?
Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 2)
Stephanie G.: Internationally dispersed Teams sound pretty exhausting. Are you telling me that you‘re no fans?
Hélène V.: I think that I can speak for everyone present that putting together internationally distributed or dispersed Teams – although dispersed is even worse – are not what we would advise managers to do. Yes, Scrum can be applied in such situations – but a lot of the fun and simplicity are taken out of the process. It is a challenge, which – of course – we are all willing to take on, but if a manager would ask me for my opinion, I would certainly advise the setting up of co-located Scrum Teams. (nodding all around)
Bernd K.: If I were a manager and I had to choose between training people on-site or investing in skilled staff abroad, I would certainly take the ones that are on-site.
Deborah W.: I second Bernd. But one has to admit that the wonderful thing about agile methods and Scrum is that they offer great practices, such as Pair Programming, for transferring and building up the skills of one‘s employees. However, this really depends on the product, the people, the necessary skills, as well as the available time and budget.
Kristina K.: Time‘s the word. If we‘re talking about a project where certain skills will only be necessary for a few months, it would probably be smarter to buy this kind of know-how. If we‘re talking about three years, then I would go for the more sustainable option of ensuring that the skills are available on-site.
Ina K.: In the case of three months, I would also aim at having the people with the necessary qualifications and competence flown in and sit together with the rest of the Team. After all, there will always be a small percentage of Team achievement that cannot be reached due to it being distributed.
Hélène V.: I second that. As a manager, it is important to figure out how to motivate the naturally distributed Team members to spend the necessary time together in one location. If one takes your case for example, Stephanie, one could have offered the German and Indian Team members a salary for 12 months and the challenge for the entire Team to complete the product within one year. The Team spends that time together in the third location Vietnam and if they finish the product earlier, then the 12-month salary is still paid, but the Team members can return home early. This is just an example – it’s up to the managers to think about ways to motivate their Team members to get together in one location and maximise their productivity.
Stephanie G.: I like that idea. But it again points to the general opinion that you would all strongly recommend to avoid creating distributed Teams?!
Christof B.: As Hélène has already said, if we were given the choice as managers, we would try to keep the Team in one place. There are, however, a few scenarios that I could live with. Firstly, the ScrumMaster would have to sit with the Dev.Team. If the Product Owner is not able to do so, he will simply have to start travelling more frequently in order to build up a good relationship. He would furthermore have to offer a dedicated hour per day (at least), where he is strictly available to the Team for answering any questions and give information or feedback. The other important thing to watch out for when splitting a Team is that it should be equally divided. It is super difficult when there are six persons sitting on one end of the telephone receiver, and only one or two on the other.
Stephanie G.: Thank you. So to sum up your statements, we may advise managers to
- avoid distributed or dispersed Teams
- motivate Team members to travel frequently or move to the other location(s)
- build up Team members‘ competences sustainably by using agile methods
- make sure to split the Team evenly, if the dividing up cannot be avoided.