11 tips that will ensure early death of a Distributed Agile Project

28 Jan, 2009

You never believed in it. You wondered if it could ever have worked for anybody in past two decades. However, it has arrived. You are going to work Agile and worst still Distributed Agile Offshore. You were skeptical about this right from the beginning when it started in your company but no one would listen to you.
Here are 11 tips that will ensure early death of a Distributed Agile project:

[Though this blog has been written in negative tone, the objective is to make people working with offshore teams aware that they can contribute to the success by avoiding some common mistakes. It does not reflect practices observed in a particular project. It is just a collection of various observations that contributed to making offshore projects less successful. Please feel free to add more.]
See the positive spin on this list here
1. Involve offshore team in the project after couple of sprints once onsite team has understood the project vision, road map and made key technical choices.
2. After the involvement of offshore team, keep making all important design decisions with your small onsite team. Frequently communicate about when the offshore team makes mistakes because of lack of communication from your side about important design decisions.
3. Keep offshore team very small i.e. 2 persons or less. Keep onsite team at least 3 times bigger than the offshore team so that the real action can take place only onsite.
4. Blame every problem in a project which could be due to wrong specifications, technical debt, broken builds and wrong technical choices, on offshore team. You will be surprised to see how easy it is to convince your stakeholders that these problems are caused by working with a Distributed Agile Offshore team.
5. Never give honest feedback in the project retrospectives. Keep telling Agile Offshore team that they are doing pretty well so that their drive to improve their productivity and quality remains low.
6. Avoid collocation with offshore team at any cost. Keep offshore team always at a distance from the product owner, onsite developers, testers and other stakeholders as much as possible. You can use high travel cost as a good argument against travel which your manager will accept at ease.
7. Despite of your efforts if your collocation takes place then make sure that no onsite team members pair programs with offshore team member. If possible arrange separate desks for offshore team members.
8. In a sprint ask offshore team to handle simple tasks that nobody onsite would like to do. Grab the challenging user stories during the sprint planning for onsite team.
9. Keep refactoring the code during the weekends and in the evenings with very little communication about it with the offshore team.
10. Re-write a significant part of code delivered by the offshore team with out any communication to the offshore team. Tell your manager that you are too busy because of some problems in the code of offshore team that require urgent attention before a release can be made.
11. Never let offshore team fix the coding problems created by them. Do it yourself and communicate frequently about it to your onsite stakeholders.

Started as a C and Visual Basic programmer in 1993 in India. Worked as a consultant in software implementation and software development projects in Europe before moving to India in 2006 to setup Xebia office in Gurgaon.
Newest Most Voted
Inline Feedbacks
View all comments
13 years ago

You are making a point with this, treating offshore team as less competent is the biggest mistake in my point of view, the most harmful thing to do.
I’m interested in distributed teams, how to manage them and the best practeces for achieving success.
Do you have metrics/measurements for this work you have done?

Puneet Jain
Puneet Jain
13 years ago

The only problem with distribute agile is the level of both teams in terms of domain knowledge, skill set and ownership. if any one of these are not balanced then obviously the ( superior ) team may not take other team seriously. So it can work only once the weaker team has proved its knowledge base and skills to other team.
I am assuming that both teams are not at the same level and this is a fact in context of many companies running offshore businesses.

Raja Poladi
Raja Poladi
13 years ago

The author in general seems to be against offshoring and starts off with the asusmption that distributed agile can not work. Puristic adoption of traditional processes are probably a key reason why Agile models have shot into prominence & trying to be puristic about Agile is really not advancing but retrogressing.
The question to ponder is how can we adopt & adapt Agile in a distributed mode (fully recognizing the challenges) so that we can realize the benefits (most if not all) to be expected from Agile process while continuing to leverage the cost advantage of offshoring/global sourcing.
There are many projects that have been and are being quite successfully in distributed agile which many large outsourcing/offshoring organizations are delivering including the one that I work for.

Serge Beaumont
13 years ago

LOL, Raja, you could not be further from the truth :-). Anurag is the director of Xebia India, and one of our main unique selling points is Agile Offshoring! I’m from Xebia NL myself, and I can tell you that we do quite some cool stuff in offshoring. Have you never seen other “how to ensure the death of…” lists? In fact they state the opposite case, like this one does.

13 years ago

I totally agree with you, as I have seen some examples of these through the various projects I have worked in, whether Agile or not.
I can understand that due to the fact that the offshore team is “beyond” control, it is usually treated with suspicions; blamed for mistakes, and kept away from key decisions.
Since Agile is all about trust, this trust has to extend to offshore Agile as it applies to the onsite Agile teams.

Explore related posts