The Offshore Hype

If you're shopping around for development work, you've probably
noticed a number of firms marketing offshore software development capability.
It's a bit of a buzz word these days, one that drums up different
ideas for different people. Most identify the term with lower rates,
and this is certainly true. Those with some first hand experience may
have mixed views on the impact of timezone differences, language
barriers, culture shock, politics, etc. The reality is, certain
challenges must be met for offshore rate benefits to have a positive
impact on an overall engagement. Not all offshore operations are
created equal, so let's take a look at the factors that contribute to
our success.

Our Background

RJB has employed developers in the Philippines since year 2000.
Over this time period, we've helped cultivate one of the fastest
growing talent pools in the world. The developers in the Philippines
are second to none, and we hand pick the best.

Over the past 15+ years, we've been refining our onshore-offshore
personnel logistics in the context of our Combined
Agile and Waterfall SDLC. This article is a brief overview of our
experience and capability. We hope you find it useful. For more
information, or for advice on your reducing your development costs,
don't hesitate to get in
touch.

Also, the results oriented reader can skip the preamble and jump to
directly to a description of our approach, or what we like to call
our personnel logistics
inversion.

Location Matters

Location is incredibly important. The core arguments in this
article will apply to any offshore operation. However, you really can
get off on the wrong foot by choosing a poor development location.

Our offshore center is located in the heart of Makati,
the premiere business district in the Philippines. This is a far cry
from Eastern Europe, India, Central America, and other locations in
South East Asia. Makati is major tourist destination, because it's
safe and familiar. With a 100+ year strong US relationship, the
language, culture and values of our customers are the norm in the
Philippines. In short, we hope you're excited to visit us!

Our Philosophy

"There are two kinds of companies, those that work to try to charge
more and those that work to charge less. We will be the second."Jeff
Bezos

Offshore software development can present some cost advantage over
onshore development, thereby contributing to "charging less" and
being more competitive. The key is to employ offshore resources in a
manner that mitigates risk, while maintaining good communication
between onshore and offshore resources, particularly in the areas of
changing requirements and transparency with respect to project
progress. Here are some key points to remember:

Relationship of Trust - It's critical to establish a
relationship of trust between onshore and offshore resources. Like
any relationship it requires work. When times are good it's
relatively easy. When times are tough - e.g. when we're under very
tight deadlines and stress levels are rising - focus on the fact
that we are, in point of fact, one team. It's at times like these
when good communications and transparency come to the fore.

Don't set yourself up for failure - Establish
reasonable schedules with thoughtful deliverables, and do
transparent risk analysis on a regular basis to avoid 11th hour
surprises. In order to establish reasonable schedules, funnel
requirements and enhancement requests through the appropriate
onshore/offshore teams before making the schedule commitment to the
client. To support this activity, development teams need to be able
to respond quickly with estimates based on the new requirements.

Location Planning - Choose the location for
development activities carefully. Some activities will naturally be
more client facing - while video conferencing technology has come a
long way, there may be a case for using onshore resources for
requirements analysis, integration of offshore deliverables, or
demonstrating a prototype of a new Feature to a customer.

Regular Meeting Times - Establish regular meeting
times that take into account different time zones. Due to the
geographic distribution of the team it may be necessary to adjust
meeting schedules to accommodate multiple time zones.

Review Deliverables - Regularly review project
deliverables both in terms priority as well as development status.
Adopt the "Show Me" approach (e.g. demo), to avoid the 95% complete
syndrome

Share a Roadmap - Having a vision of the big picture
will help your team during the numerous detailed judgments they
need to make while developing your software.

These are just guidelines. However, as we drill down into the
specifics of our onshore-offshore model, we hold each assertion up
against this recipe for success.

The Logistics Problem

Most practitioners will agree that co-located teams outperform
distributed ones. The entire team, from the Project Managers to the
Junior Developers, can benefit from full time co-location. Likewise,
onshore stakeholders and Subject Matter Experts (SMEs) should have
face time with the entire team throughout the entire
SDLC. So the challenge is this: how can we bring a team together
that, by the very definition of offshore software development, is distributed?
Answer: We do it the old fashioned way, by increasing team cohesion
and reducing coupling between teams.

The Traditional Approach

The traditional approach to personnel logistics with onshore-offshore
project teams can, in our opinion, decrease team cohesion
and increase coupling between teams. This is precisely the
opposite of what we would like to achieve. It can be summarized as
follows:

A portion of the team is stationed onshore with the
customer. As customer facing resources, these folks are always the
natural leaders with the strongest communication skills. Typical
onshore resources include Project Managers, Lead Architects, Senior
Business Analysts, etc. They are billed at onshore rates.

Requirements and architecture are managed from
onshore. There is little choice on this front - the people best
suited for the tasks are already stationed onshore. Again, onshore
rates will apply to these deliverables.

Construction (i.e. programming) is performed at the
offshore software development center. The offshore team members interact
with the customer through the onshore "liaisons".

There are some obvious implications with this approach. The
team is clearly separated and production of certain deliverables will
suffer based on this separation. While many customers enjoy having
senior project team members on site, this draws critical expertise
away from the rest of the implementation team which is located
offshore.

The separation increases the communication requirements between
onshore and offshore personnel resulting in increased coupling. At
the same time, onshore and offshore personnel operate less
efficiently due to decreased cohesion. Ideally, SMEs interact
directly with feature developers. When SMEs are forced to interface
with the developers through on site "liaisons", the communication
pipeline can feel more like drinking straw. There is also the issue
of rates, the primary driver for offshoring in the first place.
Moving the most experienced resources onshore creates a significant
increase in the blended rate for a project.

The traditional approach of separating the team into onshore and
offshore groups also has specific effects on team dynamics and
morale. Simply stated, it can promote an "us and them" mentality, where
onshore and offshore resources feel like members of separate teams.
The team as a whole is much more likely to fall into "finger
pointing" and other "blame game" tactics if/when communication failures
lead to project set backs. This runs totally counter to the philosophy we want to promote.

RJB's Personnel
Logistics Inversion

Based on our experience, the traditional approach causes more
problems than it solves. It also flies in the face of 40 years of
software development practices that have taught us unequivocally that
we must increase cohesion and reduce coupling in order to have well
designed software, and well designed teams. However, rather than
"throw the baby out with the bath water", we address these issues
with a few well placed adjustments.

The Role of the Offshore Software
Development Center (ODC)

"...software should be architected, designed,
developed, and tested offshore..."

Our first departure from tradition is the role of the offshore
center in our SDLC. The historical notion of offshore software development
centers is, essentially, as cost efficient code factories. It's based
on the invalid assumption that onshore resources are more talented
than their offshore counterparts, and that solutions must be
conceived onshore and shipped overseas for programming. There was
perhaps a time when this held some truth, but times change.

We maintain that software should be architected, designed,
developed, and tested offshore. By doing this we keep the entire
implementation team in one place. We also maximize savings with low
offshore rates. All that remains is to solve the communication
pipeline with the customer.

Project Scoping - Senior Delivery Team Members Go
Onshore

As per our Combined
Agile & Waterfall SDLC, we kick the engagement off with a
Project Scoping. The idea is to perform sufficient analysis to
articulate high level business requirements, identify project risk
areas, coordinate across the organization, and make preparations for
a follow on Agile development phase. The logistics of an
onshore-offshore Project Scoping work like this:

Nearshore or offshore analysis of project objectives
that results in Findings and Recommendations, including high level
schedule and costs

Onshore presentation of Findings, Recomendations,
high level schedule, and costs, to the client

Note that this service offering can be provided on a stand alone
basis, or as the first phase of an Application
Delivery. For a more complete description of the Project Scoping
service please see Project
Scoping Service.

Agile Development - SMEs Go Offshore

Strap in SME's you're going to the Philippines - at least for a
visit. See the operation, meet the people, check out Makati, and get
involved with the agile development team.

There are very practical reasons to have the project SMEs
rotate through the offshore center. As we stated above, the
traditional approach works the other way around, where a few key
offshore resources are sent onshore and often remain there for the
duration of the project. Here's our logic for inverting the paradigm:

Person on the ground - First and foremost, it feels
good as a customer to have trusted staff on the ground where the
action is happening. Trust relationships don't happen overnight,
and there's nothing more reassuring than having offshore progress
reports corroborated by your own people. We've also found it
helpful in the past to have SMEs at the offshore center demo
software to their co-workers onshore. Again, this reinforces
development progress, by demonstrating working features in the
hands of real users.

Increased Engagement - It can be difficult to engage
SMEs during their day job. This isn't a shot against the SMEs, it's
recognition that operational demands are rarely put on hold for
SMEs collaborating on a project. They are basically expected to
fill their regular full-time role, and still be available to answer
questions. In our experience, engagement is increased by a change
in schedule and environment. By getting SMEs out of their office,
and by temporarily removing all (or some) of their day to day
responsibilities, we can improve focus on requirements and user
experience. We see similar strategies used in team building
exercises - put the team in a new environment to foster creativity
and engagement.

Unthrottled Communication - When SMEs rotate through
the offshore center, we remove the bottle neck of communicating
through onshore liaisons. This is really the only way to unleash
the strength of Agile, and allow SMEs and development staff to
rapidly converge on features. Ultimately, we are talking about
saving time and money, and our experience shows that rework across
sprints is significantly reduced with this approach.

In the traditional model, liaisons are delivery staff at the
customer site. Under the inverted paradigm, the liaisons are SMEs
visiting the offshore center. Whenever the liaison has to appeal to
another SME for information, they are actually contacting a
full-time co-worker in their own organization! They know who to
speak with, when to get in touch, and how to ask the right
questions. Compare this with the traditional approach of having an
on onshore team lead from the delivery teaming trying to dig up
business information and forward it to the offshore team.

Team Building - Our final argument for the inverted paradigm is
it's effect on team morale. Consider a scenario where pairs of SMEs
are rotated through the offshore center every 2-3 weeks. Just like
the traditional approach, we always have one or more liaison(s) to
bridge the gap between onshore and offshore staff. However, by the
end of the development phase, the inverted approach ensures that every
SME has met every project team member. Compare this with
the traditional approach, where only a few hand picked individuals
ever meet the customers team. You don't have to be a psychologist
to realize there is no substitute for face to face meetings, team
lunches, or after work get togethers. These things go a long way
toward fostering the inclusive relationship we describe above.

User Acceptance Test (UAT)

As we stated in The
Role of the Offshore Software Development Center (ODC), software
should be architected, designed, developed, and tested offshore.
That testing should include System and Integration Testing (SIT), and
some witness testing by SME's during their offshore visits. However,
it's important that some of the final testing activities are
performed onshore. In particular, we want to engage end-users who
will be hands-on with the new system. This involves setting up a User
Acceptance Test (UAT) environment, where software that is very close
to its finalized form is used and vetted by those same users. This
step has the additional benefit of engaging those users and getting
buy in and confidence in the new system prior to production release.

Production Release

Now that the final system is tested and accepted by both the
client executive, as well as the end-users, we must co-ordinate the
release of the new system into production. This co-ordination is
ideally done with face-to-face meetings onshore between client staff
and senior members of the offshore delivery team. It will likely also
involve other client departments who may not directly be affected by
the new system, but need to be aware of the deployment. Due to the
number of client staff that may be involved, it makes economic sense
to have a few members of the delivery team go onshore. Using this
approach, senior technical delivery team members will also be on hand
to resolve any last minute technical changes involved in setting up
the production environment. Some senior technical specialists from
the delivery team remain onshore throughout the production release
until an agreed upon time where the deployment is determined to be
stable. After that time, the delivery team members can return
offshore, and any periodic bug fixes (if required) can be done by the
offshore team.

This concludes our discussion on how onshore-offshore software development
teams work together efficiently to make the most of offshore cost
benefits, while delivering a quality product on-time, and on-budget.
We hope you find it useful. For more information, or for advice on
your reducing your development costs, don't hesitate to get in touch.