Distributed Agile and Offshore Teams: Five Myths

Three years ago, I wrote a blog post on the myths and misunderstandings in implementing agile methods.  That is one among the frequently read posts in my blog site. I am writing this post to share five myths on adopting or implementing distributed agile in onsite-offshore model involving two or more locations and one or more organizations.

Myth 1: Agile is for collocated teams only

Other Forms:

a) Agile does not work well in onsite-offshore model.

b) You cannot succeed in agile projects with geographically distributed teams from multiple vendors across two or more continents.

Trust me, there are several organizations that hold on to collocated agile and say no to geographically distributed teams. Reason? May be they are apprehensive about what can go wrong. May be they have not tried it out and they want to maintain their status quo. May be they have several unanswered questions and they are not asking the experts.  May be something went wrong and they don’t want to try again. With reasons like these, they believe that agile does not work well in geographically distributed teams.  Meanwhile, there are several organizations that have succeeded in executing projects implementing agile practices with distributed teams.  Agile is no longer for collocated teams only.   Adoption of distribution agile is happening all over the world.

Myth 2: Distributed agile impacts product quality

Other Forms:

a) Team distribution in agile projects results in poor quality.

b) Distributed teams practicing agile are not consistent in quality assurance.

Lack of focus on quality is what impacts product quality. Distribution of teams doesn’t.  When there is lack of focus on quality, why blame geographically distributed teams or think that distributed agile impacts product quality?  When you practice agile, you come to know quality issues ahead of time and you and your team get an opportunity to improve quality.

Myth 3: Remote teams need developers and testers only

Other Forms:

a) Onsite manager will have to have daily 1-1 interaction with remote team members.

b) Onsite manager has to micromanage remote team members.

The initiation of distribution in most cases starts with staff augmentation. You induct one or two developers and testers at a remote location and call it a geographically distributed team.  And you introduce agile practices.  The structure of your team and the dynamics among team members result in delivering a good or bad product.  When you pay attention to team composition and structure your team with a leader – say Scrum Master or Agile Project Manager, and induct developers and testers, you are providing an opportunity for them to be cohesive. That will help them perform as a team.  Augmented teams with no collocated leader does not work.  In other words, you cannot produce results by assigning a remote Scrum Master to work with offshore developers and testers. Don’t you agree?

Myth 4: Agile is not suited for large distributed projects

Other Forms:

a) Traditional approach yields better results in large distributed projects as compared to agile methods.

b) Agile fails in large projects when teams are distributed.

c) Distributed agile and offshoring for large projects is a bad combination.

We think that large projects and distributed agile is a deadly combination. In fact it is not so.  When you learn how to introduce and improve team structure, governance mechanism, continuous improvement and the likes you are bound to improve and succeed.  There are case studies on large distributed agile projects from every other organization.  All you need to do is to connect with experts who have been there and done it to start your journey.

Myth 5: Distributed agile comes with too many overheads

Other Forms:

a) Distributed agile projects consume more efforts than required because of several meetings and documentation needs.

b) Communication and coordination impairs productivity in distributed teams.

c) Detailed requirements or user stories are required when you work with distributed teams.

There are overheads when we execute projects with geographically distributed teams whether or not we follow agile practices.  Agile offers early visibility and predictability at regular intervals. Can we say no to this advantage and wait for last minute surprises?  From iteration to iteration, we need to optimize unnecessary overheads in order to get benefits or results.  Let me tell you, if you know how to optimize, you will agree that the overheads are not too many!

I am sure there are several other myths about distributed agile.  Do you want to share any? Let us discuss.

Related Post:  Agile Myths and Misunderstandings