Why offshoring Agile development often doesn’t work

by Jennifer Borek on October 7, 2014

Lorraine is a seasoned Agile Coach and Certified Scrum Master with over ten years of Agile experience managing software development and implementation projects. She has published about ‘Agile and offshoring’ and ‘how to improvise Scrum’ in CIO Magazine (tinyurl.com/pvkd99n), ComputerWorld and the Agile Journal.

Lack of communication and teamwork leads to poor productivity and a solution that doesn’t provide value, says Lorraine Pauls Longhurst.

Many enterprises these days are outsourcing software development to offshore teams. Your organisation may have even tried it as a way to get access to highly skilled resources cheaply, and scale development resources up and down as you need them.

But more often than not, I hear of project failures that are blamed on offshoring. People say things like: “The offshore developers just didn’t understand what we needed” or “They developed completely the wrong thing.”

So why is it so hard? The main cause for these types of problems is a failure in communication and lack of teamwork. This has been my experience as an Agile delivery manager and coach.

As an example, let’s take a typical software development project following Scrum (the most popular Agile framework) such as the deployment of a customised ERP system.

The entire team including developers, business analysts, testers and a product owner (who represents the business users) sit together in the same room.

The group should communicate informally and act like a team by following Scrum guidelines such as letting members choose their own tasks on a shared board, and ensuring everyone helps out to meet the bi-weekly (sprint) goals.

The product owner can easily illustrate requirements by writing something on the board or giving a quick verbal example. And when you do it right, Agile enables organisations to develop a solution that can change as the business requirements are adjusted.

It enables you to deliver a working solution to users within a couple months with only the highest priority features to start. Then the team re-aligns the solution by continuously communicating with the business (or product owner).

I was involved in one project where the product owner verbally explained requirements to the onshore developers and wrote down requirements for the offshore developers.

It was pretty clear that rather than trying to resolve communication issues, they were just trying to avoid them. Instead we put tools in place to ensure the product owner was able to easily communicate face-to-face with everyone consistently, in as simple a manner as possible.

Now, take that same ERP deployment, but have the team based offshore. The team members have never met each other, are not all sitting together and do not have the same working hours.

Due to the lack of face-to-face communication, cultural differences and time zone issues, the developers start to misunderstand requirements. In an attempt to close the communication gap, the product owner starts to use more written communication, which causes more misunderstandings.

The next thing that happens is because the team has never met one another, the onshore developers don’t treat the offshore developers as part of the team.

The offshore developers start to work on their tasks independently, become less likely to clarify aspects of the project, and because they feel that they need to fend for themselves, they start to blame each other when something goes wrong.

In my experience, this lack of communication and teamwork leads to poor productivity and a solution that doesn’t provide value.

Make it work offshore

So how can you make Agile work with offshore developers? You need to get back that informal communication and teamwork that is there on a successful Agile team.

You need to overcome the issues that arise due to the fact that the team members have never met one another, are not all sitting together and do not have the same working hours.

All team members must be treated the same, and communicated with in the same manner, whether they are onshore or offshore.

Increase informal communication

In an Agile project, there is usually less written documentation and more face-to-face communication. The product owner verbally explains business value rather than giving the team detailed functional and technical requirements.

If the team understands the value of a requirement (or user story), then they are able to discuss alternative solution options. I believe this is one of the key things that can make an Agile project provide more value than a traditional project approach.

To get the entire team to communicate face-to-face more, I suggest using a ‘blended’ team. Rather than an entire outsourced team, a few offshore resources are embedded within the onshore development team.

The reason I’ve found that a blend of both onshore and offshore resources works well is it’s easier to ensure that requirements are communicated in an Agile manner (not just written down and handed over to the offshore team).

I was involved in one project where the product owner verbally explained requirements to the onshore developers and wrote down requirements for the offshore developers.

It was pretty clear that rather than trying to resolve communication issues, they were just trying to avoid them. Instead we put tools in place to ensure the product owner was able to easily communicate face-to-face with everyone consistently, in as simple a manner as possible.

Video conference is the closest thing to face-to-face communication with offshore team members. When coaching a team, I ensure that team members are talking to each other informally by video conference at least once a day real-time, during the overlapping working hours (instead of by email or instant messaging).

We used a ‘video wall’, where we had a large TV screen permanently on (using Skype or something similar). The entire offshore team sat together in one room so we could easily see everyone.

Onshore developers would walk over to the screen, say ‘hi’ and have a brief chat with the rest of the offshore team.

With Scrum, the team uses a task board to determine what needs to be accomplished in the sprint. Rather than a physical task board, we used an on-line tool to review and update the task board.

Offshore developers chose tasks themselves rather than having them assigned to them and everyone could see who was working on what. When issues arose, everyone pitched in to help out to ensure that all the tasks were complete.

Focus on teamwork

Everyone knows the benefits of teamwork in principle, but in practice it is much more difficult especially when part of the team is based offshore. There are a few methods I use to get everyone to work together towards the same sprint goals.

I have found that the only way people start helping each other out is if they feel like they really know the other team members, and understand what motivates them.

To encourage this kind of social interaction, we did a video conference chair race – India vs Australia. It was a fun way to get the team joking around with each other.

We also brought the offshore team members over to Australia for a few weeks. A little real face-to-face time went a long way.

I mentioned earlier that I believe if the team understands the business value behind a requirement (or user story), then they are able to discuss alternative functional and technical solutions and come up with what is best.

To make this work, all the team members must speak up and act like an equal member of the team.

Early in one of my projects, I found that the team was under-estimating the amount of development work and one of the offshore developers wasn’t able to deliver on time.

Our onshore designer was coming up with innovative user-friendly ideas but what I wanted the developers to do was discuss the designs as a team and come up with the best option that still fit within the timeframes we had.

To help resolve this issue, I asked one of the offshore developers to take a leadership role in the planning session and although he was to listen to the others for their input, it was up to him to give the estimates for the tasks.

The one caveat was that he then had to meet those estimates. This exercise seemed to give him the confidence to speak up much more in later planning sessions and act like an equal team member.

To make offshoring work with Agile, you need to overcome the communication and teamwork issues inherent in a team that have never met each other, are not all sitting together and do not have the same working hours.

Overcoming these issues is a challenge, but with the implementation of a ‘video wall’, an on-line task board, plus some coaching, you can still gain the benefits of Agile with a ‘blended’ team (mix of onshore and offshore developers).

http://www.cio.com.au/article/547142/why_offshoring_agile_development_often_doesn_t_work/?fp=16&fpid=1

This post originally appeared on CIO Magazine on 6/14/2014.

 

{ 0 comments }

Getting to Agile and the Coach’s Role

September 23, 2014

Allison Pollard’s goal is “To Teach and Delight.” Her goal is to help people discover and develop their agile instincts. She enjoys mentoring others to become great Scrum Masters, coaching managers to grow teams that deliver amazing results, and fostering communities that provide sustainability for agile transformations. Allison blogs at over at To Teach and [...]

Read the full article →

The Narrative Practice of Building a Team

July 2, 2014
Thumbnail image for The Narrative Practice of Building a Team

Elinor Slomba - (@artsint) has nearly twenty years’ fundraising and management experience combined with training in ethnographic field research methods and Agile project management frameworks.  She collaborates with professionals in visual, performance and literary arts as well as software development and other technical fields to deepen understanding of principles necessary for innovation. Her company, E. Slomba [...]

Read the full article →

Why is it so hard to find experienced Product Owners?

May 28, 2014
Thumbnail image for Why is it so hard to find experienced Product Owners?

Lynn Winterboer - (@agilelynn) With a proven background in a variety of data projects and agile practices, Lynn Winterboer teaches and coaches DW/BI teams on how to effectively apply agile principles and practices to their work. For almost 20 years, Lynn has served in numerous roles within the analytics, business intelligence and data warehousing space. She [...]

Read the full article →

Standards are not the answer

May 1, 2014
Thumbnail image for Standards are not the answer

Diane Zajac-Woodie (@agilesquirrel) has spent the last six years redefining the business analyst role as more than a requirements dictator. Through open and honest conversations, Diane guides her business partners toward creative solutions that solve problems and eliminate waste. She shares this same approach with her technical teams, facilitating communication, cooperation, and continuous learning to ensure [...]

Read the full article →

The Story of Clean Language and the Gecko

April 15, 2014

Andrea Chiou is a consultant in change management, team facilitation, agile and lean methods, and team and personal coaching. She blogs about her experiences at Adaptive Collaboration. When we moved to Africa, and I was just going into 6th grade, I learned by observing that shooting off the tail of a gecko doesn’t do anything [...]

Read the full article →

Book Clubs at Work – Are You Serious?

April 1, 2014

Em is a senior manager in Information Management. She is a certified Scaled Agile Framework Program Consultant (SPC) and an active member of the Agile community. She frequently speaks about her experiences with Scaling Agile and Agile Data Warehousing at conferences across Australia and the United States. As mentioned in a prior post, the idea for the [...]

Read the full article →

Growing Scrum Masters for the Future

March 18, 2014

Helen Meek is an experienced Agile Consultant and Coach with a passion for helping people, teams and organisations succeed and meet their full potential. It’s been a pretty interesting couple of weeks with my adventures taking me to Kingston for a new client (note don’t get on slow train!), holding the Agile Coaching Exchange with Liz Keogh, [...]

Read the full article →

I’m being an Agile player

March 4, 2014

Natalie Warnert (@nataliewarnert) blogs at Confessions of a New ScrumMaster.  Here she is, talking about dating Agile. So I’m being an Agile player. I’m dating a few different versions of Agile to see which works best while trying to keep it from the other methods I’m test driving. Don’t tell Scrum that I was scoping out [...]

Read the full article →

Combining Kanban and Scrum – lessons from a team of sysadmins

February 6, 2014

Kate Terlecka is an an agile coach and a Professional Scrum Trainer. She wants to change something in the way people in Poland make software, so she founded the Brass Willow initiative, which is bringing together experienced trainers, coaches and technical experts who want to do something more. Kate blogs about Scrum, Lean and Agile at Control [...]

Read the full article →

You can’t focus on how far you have to go. Focus on how far you have come.

January 23, 2014

Valerie Santillo is a Perpetual Agile Student who is passionate about this methodology and hungry to learn more. Valerie’s blog, Adventures in Learning, covers all aspect of agile practices, principles, and values.  Here’s Valerie… You can’t focus on how far you have to go. Focus on how far you have come. It doesn’t matter what [...]

Read the full article →