Dealing with challenges in distributed teams

How many people are in the Dev Team ?

How are the skills distributed ?

My idea is maybe it could make sense to split into several colocated teams instead of a big distributed one ?

Thanks Olivier. Its a team of 10; 7 in India & 2 at San Jose. The PO is located at Chicago.  

the complexity of the product has increased and constant interaction has become a necessity

The more complex a system is, the more unknowns there are which need to be brought under empirical control.

Why is the complexity of this product thought to be increasing over time, rather than decreasing?

I'm also curious how you update the US team with there being a 12 hour time difference. Do you do it via email or other virtual tool or is the US team waking up at 5 AM to have a conference call? What tools or methods are currently employed for discussion and collaboration?

It also seems odd to have 7 developers in one spot and only 2 in another. Is there a big differentiation in skills between the India reps and US reps? As in are the 2 in the US mainly testers or more experienced developers that the rest of the team depends upon? 

Thanks Ian & Curtis.

Yes. The complexity is definitely increasing as its a new product, new team, and various unknowns have started to surface. 

Currently, we use emails with a verbal agreement that they should be responded to within a day's time. We have the Daily Scrum around 8 AM IST, which suits the US team as well. The other ceremonies are still a challenge with respect to time but I rotate the inconvenient timings between the two geographies. US team consists of 1 UX designer and the other a senior developer, both critical members. 

My concern is how can I increase collaboration between the team members. What's happening is: Say, in a call, an Indian team member introduces himself as, "I am Ashish from India team." The US person says, "Hi, I am Austin from US team." Though it sounds minor, I believe it reflects the mindset that somewhere there's a gap in collaboration.  I would prefer them say, "Hi, I am Ashish/Austin from AI team." :-)

Good that you're doing the Daily Scrum at a time that is not a huge inconvenience to both teams and that you rotate the other ceremonies so the US team is not always getting the short end of the stick. 

Email is okay but what other tools do you use that can be used for collaboration? What do you use for backlog management? 

I think you are wise to have the concern of the "US Team" and "India team"; that conveys the message that you've got 2 completely separate teams that just happen to work together. One way that you could manage this is replacing "team" with "office". So instead of "Hi, I'm Curtis from the US team", I would say "Hi, I'm Curtis and I'm in the US office." It's a very minor change but it does 2 things, (1) it lets the team know where the person is and (2) it doesn't seem like there are 2 separate teams. 

I would also try to find a more collaborative tool to use and limit emails to be used only when absolutely necessary. Here is a good link that has a good suggestion of virtual tools for scrum and kanban teams:    http://www.opensourcescrum.com/

The complexity is definitely increasing as its a new product, new team, and various unknowns have started to surface. 

Perhaps it would be best to highlight the risks of having a dislocated team at this early stage, before problems compound any further. Transparency is needed over the cost and impact of any constraints on team efficiency, and the commitments the team can make. If the team cannot be satisfactorily co-located, whether it be physically or virtually, then they may need to limit the scope of each Sprint in order to make outcomes predictable and achievable.

A team can sometimes move to a dislocated model once complexity has been brought under empirical control and development has stabilized.

@Curtis - Thanks for the suggestion of using the word - office. I like that and have already implemented it. It's working good now. Also, thanks for the URL - great references. We are already looking at Agilemantis.

@Ian - Thanks for the suggestion. I have escalated the suggestion with the senior management and hoping for a positive reply. If even a couple more sprints can be managed that way, I believe it would create a great transformation with respect to collaboration with the team.

Hi,

In my opinion scrum is not working well in distributed teams. The crucial thing in agile are meetings where team members can discuss things face-to-face. I am also part of distributed team Europe-Asia and there are problems with it. We are starting with some new structure from new year but I am sceptical about it.

Regards,

Marek

@Markek, it is all about what you put into it.  I have worked on several distributed Scrum Teams which worked quite well, but you need a really good Scrum Master and an engaged Product Owner for sure.  Here is a link to a video that talks about distributed teams and Scrum, an article on working with distributed teams, and a blog to get you started.  

Good luck with the new year and hopefully success. 

I am also part of distributed team Europe-Asia and there are problems with it. We are starting with some new structure from new year but I am sceptical about it.

Before introducing complexities such as team dislocation, has your organization first evidenced a good ability to implement Scrum with co-located team members?

Perhaps if there was better evidence of this mastery, with clear experience to inform decision-making and to and fall back on, there might be less reason for scepticism about taking on such additional risk.

I have been working in one project with Polish only teammates and it worked quite well. Of course even here we have some persons more enthusiastic and some less involved. Some persons were sleeping on the planning meeting and it is hard to cope with this.

Regarding teammates in Asia. There are several problems. One is that they are in general younger and less experienced. Additionally there is strong division between analysts and software engineers. In Poland several software engineers has become analysts, as me for example. In order to form a team we should all agree that we are equal and we should be open to giving and receiving ideas. My technical advices were often ignored by Asian teammates. The reason is that they think analyst should prepare functional specification while software engineer decide on how develop it technically. It is not the case in agile team where it is possible that analyst do some programming and software engineer can do some testing.

Another problem with distributed teams is that we don't know what are they doing, how they are working, why they are working in this way and so on. It might be the problem with your colleague in next desk as well. But for collegaue in another country it is magnified.

In my opinion the main advantage of agile work in the team is that we can discuss and together agree on the solution. In distributed teams it is not possible or very difficult to achieve.

Based on experience the best way to alleviate this problem is to allow the teams to separate into two teams. Usually the offshore and onshore will separate themselves as they know they can work most of the time together. You can then have a nexus Scrum in the time that is common for both teams followed by individual scrums that each team can have. The problem here is we cannot guarantee that each team can have all the skills needed to make it truly crossfuntional. 

But because working together in a collocated environment is so important, it will be hard to decide which factor to take care off, location or skills? Making sure each team is collocated and working on developing lacking skills in both teams through KT sessions takes time but should work. For example many teams do development onshore and expect testing by offshore. This is a path to disaster. Each team should have all skills needed to release the PBI barring any integration work and dependencies that can be taken care by the NEXUS integration team.