К основному контенту

Offshore software development

I wrote down some thoughts I was having about offshore development,
which I though might be interesting from an agile perspective. I'll
follow up with another post that deals with how this stuff is related
to being "agile" in an offshore situation. But, it would be nice to
hear how people are using agile approaches to achieve the things that
are mentioned below.

--------------------------------------------------------------

Offshore software development is motivated by two factors, (i) the
lack of local knowledge workers, and (ii) apparent cost savings.

There are many different models for doing offshore development. It
can, for example, be done on a project basis, or as a long standing
leasing of a dedicated team. I will mostly discuss things related to
the latter scenario, where the offshore team is leased to maintain a
product for a long period.

Having an offshore team is for most companies a journey into the
unknown. There are many practical issues that need to be resolved. In
most cases the top priority is to staff the team, and train the team
members so that they can become productive.



Most organizations are process oriented, and will therefore, quickly
focus on implementing some process to govern the offshore development.
However, there are some more "soft" issues that arise and require some
attention.

Some of the questions that quickly arise are:

* How do we position us with respect to these new team members?
* Can we trust them?
* How much effort should we spend on integrating them into our
company?

But, the real question that you should ask is:

"How do we achieve a productive, long-lasting, relationship with the
offshore team?"

The key elements in having a long-lasting and productive relationship
are:

* Trust
* Open communication
* Integration
* Sponsor support

Getting these key elements into place is essential for success. It's
necessary to discuss these things right from the start, and before you
start implementing some kind of a "process". However, the selection of
a process can highly influence how easily you can achieve these.
Later, I will discuss how an agile process can help in creating an
environment based on these four cornerstones. For now, let's discuss
these key elements: trust, open communication, integration, and
sponsor support.

TRUST

Trust is a fragile and complicated element in all human interactions.
Trust is built on transparency, honesty, and a commitment to matching
your words and actions.

In an offshore situation, an essential part of transparency is to
communicate decisions and their underlying causes. In a transparent
organization there are no "secrets". Information should not be
filtered for different audiences. That is, certain information should
not be exclusively communicated to local team members. Transparency
also means that expectations and results are clearly communicated.
Failing to balance and communicate expectations will almost always
lead to disappointment among some of the stakeholders.

In an offshore situation it's important to communicate the company's
intentions. Why did it move things offshore, and what are its plans in
the long run? In addition, shorter term plans, such as staff changes
and a product roadmap are valuable.

Despite the best of efforts, the offshore team is always at a slight
disadvantage when it comes to information flow. They don't have the
chance to listen in on the daily chatter. This makes it even more
important to keep them up-to-date on what is going on.

Trust is essential for being able to give the offshore team the
necessary freedom. The offshore team should be as autonomous and self-
organizing as possible. Enabling that requires a solid trust
relationship.

Ultimately, trust, is based on face-to-face communication. It's very
hard to build a strong trust relationship with someone you have never
met in person. This is one of the reasons why limiting face-to-face
meetings, between offshore and other employees, to a select few is
always a bad idea.

INTEGRATION

It's vital to integrate the offshore team into the company. This goes
much further than the occasional on-site visit from both parties. The
offshore team needs to feel that it is an equal partner. A preference
for the local employees is harmful for the trust relationship, and
isolates the offshore team. Would you apply preferential treatment if
you had two teams that where located on different floors in you
building?

In order to integrate the offshore team it is important to apply free
flowing communication, where everybody can communicate on an even
level. In many cases communicate channels are much more fixed. One or
more liaisons are selected to handle all the communication. This
isolates a large part of the organization from the offshore team. It
also introduces a lot of waste in the form of slower communication
channels, and the inherent noise that comes from passing messages
between people.

The fact that the offshore team members are not explicitly contracted
to your company should not detract from ensuring you get the best out
of the relationship. Integrating and accepting the offshore team as an
equal partner is necessary for maximizing the companies return on
investment.

OPEN COMMUNICATION

Software development is much more about communication than any
technological or process aspect. It is therefore one of the weak
points for offshore development. In an offshore setting, you need to
communicate frequently and personally. The more personal your
communication paths are the better. People have a tendency to
communicate electronically, sending large amounts of emails. Unless
there are some time-zone aspects that prevent you from communicating
in a more interactive way, email will always introduce waste. The same
applies for communicating what the offshore team needs to produce.

Electronic communication in the form of specifications is less
effective than personal and interactive communication. It's good to
document decisions, but starting off with a detailed description
invites misunderstandings. This is of course, the opposite of what
detailed descriptions are supposedly good for. Making sure there is a
clear contract of what is required. What really happens is that the
product may well end up representing one interpretation of what the
written documentation conveys, but it's unlikely to be match all the
different possible interpretations of various stakeholders. The need
for rigid written specifications is one of the myths that surrounds
offshore development. When you have people in different locations it
will always be more difficult to communicate, but this barrier is much
lower than most think.

Personal communication, where ideas and cooperation are valued,
results in a new level of openness. Open communication means being
able to communicate ideas, thoughts, and differences irrespective of
the forum. It is also tightly related to the free flowing
communication mention in the previous section.

THE SPONSORS VIEW

Ultimately, it's the sponsor that shapes the environment that an
offshore team works in. Without his support it is not possible to
achieve the things that where discussed above: a communicative and
integrated team that has a solid trust relationship with the
organization.

The sponsor, in this context, is the entity that is responsible for
allocating funds for the offshore team. It can be the company CEO,
board members, department head, etc.

The sponsor needs to understand that it's in his interest to keep a
good long-term relationship with the offshore team. In particular,
understanding the cost-benefit aspect of maintaining this relationship
is key. When an offshore effort is started people tend to focus on the
cost aspect. It is one of the driving factors, and it can therefore be
difficult to accept changes to the original cost expectations. In most
cases, the "hidden" costs of moving development offshore are much
higher then expected. But, that is mostly because the expectations
where off in the first place. Expecting that you can come away with
spending less money on the "softer" issues of your offshore team than
your local team is an illusion.

The sponsor needs to understand the cultural aspects that can prevent
the offshore team's integration. He needs to set an example of support
for the offshore team. At the same time he needs to communicate
clearly to the existing employees with respect to the companies
plans.

Irrespective of their geographical location everybody associated with
the company should be treated equally, and given the same attention.
The company should invest in its offshore team members by making sure
they receive the necessary trainings and courses. Team building
activities are just as important for your offshore and local team
members.

Some may argue that it's the offshore vendor's responsibility to
handle these "soft" issues. It's is in the vendors interest to nurture
their staff, and this is one of the criteria that should be taken into
account when selecting a vendor. However, relieving yourself of all
responsibility in this area, and taking a passive stand, is harmful to
your organization in the long run. Being an active partner in shaping
and motivating your team can only enhance and protect the intellectual
capital that you will accumulate in the offshore team.

It's important that to have a more personal relationship between the
sponsor and the offshore team. The trust and openness that are
described above need to flow down from the sponsor. You cannot install
these as foundations of your organization unless it is equally
embraced by all.

EPILOGUE

The need for dedicated offshore teams of qualified knowledge workers
will increase. This offers companies the chance to recruit long-term
team members, and thereby, indirectly increasing their intellectual
capital. This is in contrast to the more "drone" based mindset that
sometimes is associated with offshore enterprises. However, for this
to be possible, it is necessary to align your offshore efforts so that
they support long-term, trust based relationships. The geographical
barriers should not distract from applying the same principles for
nurturing people located offshore or "on location". Most global
corporations archive this every day, it is only an incorrect mindset
and distorted expectations that prevent many companies from doing the
same for their offshore teams.

Cultural differences are an important parameter, and many of the
things I have discussed are not easily applied in cultures where a
command-and-control model is deeply integrated into society. In the
search for cheaper knowledge workers, the industry tends to shift from
one region to another. New offshore markets, such as China and Africa
will become mainstream in the near future. It's important to realize
that the apparent cost savings of these new regions are somewhat
offset by not being able to integrate these knowledge workers in the
same way.

Ragnar Birgisson for Agile Ukraine, June 2007, see the discussion thread

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Основополагающие принципы Agile-манифеста

Мы следуем таким принципам: Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. Работающий продукт — основной показатель прогресса. Инвесторы, разработчики и пользователи должны иметь возможность поддержив

Скрамбан - собираем лучшее

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.