Communicating requirements to offshore teams

Question

Just to give a context, there is an offshore team in India for a client in San Francisco. The offshore team is about 9 developers and 4 QA, with one project manager. I am doing onsite coordination for this team from the client location. Every sprint (2 weeks iteration) I go after the stories beforehand, understand it and give an overview during their story time. I also clarify the corner cases for them making sure every piece of requirement is clear and the scope is also well defined. Inspite of this, there are instances of surprises that come-up in the requirement as well as scope (my bad, agreed!). We have started sending mock-ups for every UI story too. But instead the team there does not put any effort to brainstorm and understand the requirement upfront, but they start doing right away without proper understanding.

At the end of sprint (1/2 days before) they ask same questions that were clarified through the mock-up and those which were clarified during story time and the subsequent mails. Finally if I say yes this is to be done etc., they say this was not clarified before. (How do I know this question will pop-up to them?)

They obviously fail to deliver sprint after sprint. The manager there does not even understand a piece of development he being a QA and has zero control of the project (unfortunately promoted as a manager of the same team, when he had tried to resign - which often happens in Indian services company). And this manager not even tries to understand that the dev or QA did not do adequate planning, brainstorming nor do their extra or little effort to understand a feature and its consequences, and directly jumps to the conclusion that the requirements are not clear. Manager also does not spend adequate time with the team and he spends time elsewhere going out! (weird, hearsay!)

There is also a severe dearth of technical and product knowledge of dev and QA respectively, and no steps are being made to improve this. In the first week I hear that they are all clear, the second week things change drastically - my guess is that is when they start to work. Every sprint it becomes worse and only harsh comments and emails are being exchanged. 'Requirements not clear' seem to be the easy way out, and Team there got habituated to saying this to compensate their incapability.

I am unable to explain this as they form a group in making this easy decision, and bounce with multiple rude emails. What would you do to get these things right? How much of adequate is adequate clarity in requirement? I am really unsure of this. (The teams in SFO are rather pretty clear with the even lesser amount of explanation of requirement.) How can I set this right? Is my guess about the offshore team right? (Excuse me for being too verbose!)

Answer 1

No guarantees on this one, but here is what I would try:

1. Either they are not understanding your documents or they are not doing the work and using the documents as a scapegoat. It is a little extreme but ask for a restatement of your documents along with their anticipated approach. Get this by the next day as a precursor to them commencing work on the sprint. This will formalize the brainstorming that you want them to do and under the circumstances I think it is a necessary step.

2. Do an honest evaluation of your documents to see if they are written using a level of English that is appropriate. The smartest developer cannot meet expectations if the language requirements are beyond what is reasonable. It is much easier to write complicated documents than simple ones and it takes continual effort.

3. It sounds like you have no contact with them throughout the sprint? If that is the case it needs to change so that you don't find out things are off track 1/2 day before the end of the sprint. You need documented daily engagement on their progress and issues.

4. Given the level of dissatisfaction that you have with their technical abilities and communication it doesn't appear that you are in a position to terminate the relationship. Can you have the client put pressure on them to apply more knowledgeable resources to the project?

5. This situation cannot afford surprises in the requirements and scope. You need to explain that to the client and ensure that it just doesn't happen. By allowing it you are reducing the likelihood that a challenged team will deliver and giving them something to use against you.

6. Finally, the most difficult thing is to honestly assess whether you need to call on your employer for some help. With sprint after sprint missed this has been going on for a while. It is painful to admit that a situation is outside our experience but much better than insisting we can do it and then failing.

Answer 2

I totally agree with Michael and Mark. Both nailed the problem with the ask for a restatement of your documents along with their anticipated approach. They're clearly not understanding the requirements. The problem is... are they trying to understand beforehand? If they're not analysing the requirements and jumping straight to the dev, they'll have a hard time down the road.

One thing you need to consider is the cultural difference in place. There's an amazing video from Robert Dempsey HERE talking about cultural differences that highlights one small detail that can change everything: Indians aren't used to say 'no', even if they don't understand what you're talking about (I'm from Brazil and I know that similar things may happen here too).

There's another point that (if I'm not wrong) Brooks mentions in his TMMM: It's unlikely you have one raising questions when you have room to assume things. It may be aligned with the original problem, requirements not clear. So, when reviewing the requirements with them, make sure you separate what they understood from the requirements docs and what they assumed based on them.

Answer 3

You certainly have a problem. Ultimately the problem is yours, even if the team is composed of total slackers. You're accountable for delivering on time; the team is accountable only to you. I'm not sure that offshore/onshore is relevant; I'm not sure that many of the details above are relevant (except that we would have asked if you hadn't supplied them.) What is relevant from POV is that you have team that is consistently failing to deliver. What are the consequences of that failure? What are the consequences to the project? What are the consequences for the stakeholders? The consequences to the team? And what are the consequences to you?

1. Although you think that you have communicated the user stories clearly and effectively (and it certainly sounds like you've done all the right things), the communication isn't effective unless it is received. First thing I'd do in your shoes is to find a way to test whether the recipients perceive that "every piece of requirement is clear and the scope is also well defined". Close that feedback loop during that initial sprint meeting. Build in a feedback loop that forces them to produce a measureable product. Perhaps have them produce the unit tests for the user stories within 24 hours of the initial briefing? Something that prevents them from pleading unclear requirements later.
2. Clearly the sprint of 2 weeks is an ineffective timeframe for Team India. They need closer supervision. Until they can produce a successful sprint, they should be required to report incremental progress daily. (Weekly would be nice, but I'm skeptical). You and Team India share a problem, and you're going to need to share the responsbility for the answer.
3. Metrics. Earned Value is your friend. You and Team India share a responsibility to identify and correct the communications problem earlier in the sprint. Shared understanding of the development process, identification of roadblocks and removal of roadblocks are the route out of that particular trap.
4. The consequence for the project is that you are later and later. I'd escalate this quickly; start briefing upwards that the project dates are slipping quickly.
   

   "Our ship date is now 4 weeks beyond our baseline; unless Team India can deliver on sprint 7, that date will slip an additional two weeks. If the slippage hit 8 weeks, the risk that the entire project will fail to deliver is 50%. If we want to mitigate that risk, we can contract for another team of developers to take over work that is currently planned for Team India."

In the end the PM can only identify problems and brief them to the appropriate stakeholders along with mitigations. I just re-read everything that @michael Boses said, and my answer converged with his more than I thought it did. He's right. Reading between the lines of your question, you've already reached this conclusion.

Answer 4

Before I start I should mention that I have managed India teams as large as 180 on over 100 projects over the last 10 years and have gone through the same exact issues. It is critical in any project to match the right skillset to the project at hand, but 10x more critical in India due to culture, communication, time differences, etc.

Other posters have pointed out the major issues;

• India culture is significantly different than US. The culture is very hierarchical in nature and self-expression, entrepeneurship, thinking 'outside the box' is quite rare. For 90% of India developers, if the instructions/requirements are incomplete in any way, then it is highly likely that no work will be done.
• Developer quality in India is all over the board, I have experienced some fantastic developers, but mostly average/subpar developers. Out of school they are extremely green and generally require a substantial investment in training. It is very front-loaded in order to get a good return on investment. Your expectations may need adjustment if they are not already well trained and have no local manager/mentor to guide them effectively.
• Communication, although India requires English as the primary language from a relatively early age, it is generally only spoken at work. As such you will find a quite varied level of competency.

What I have done that works is to find at least one top India developer (or manager) to lead the team, communication is the primary concern, then technical competency. Without that manager it will be very difficult to succeed. In the meantime you will be up from 11:30p-3am or 6a-9a to work/coordinate/mentor/train directly with dev and QA managers. You're other alternative is to document the ???? out of everything, assume they know next to nothing about anything and document appropriately. It may sound harsh, but it is reality. You will then have to review all output constantly. Either way for a team of 14 it will be a fulltime job. Another option is to hire a contractor that is use to working with India teams to lead the effort, there is an art to working with India resources effectively.

Finding that top manager/developer, that is a whole other question...