Extreme Remote: Product Management - How can they know what I want from the other side of the earth?

Agile development promotes having the product owner deeply integrated into the development process.   That may mean having the product owner easily accessible for questions or to review incremental progress.  Ideally, it means having the product owner actually sitting within a few footsteps of the development team.

With an Extreme Remote team, a product owner is going to be several million steps away from some members of the development team.  Further, the working hours of the product manager and the remote team members do not naturally overlap.  So, how do you achieve the goal of having the product owner deeply integrated into the development process?

You will need to seek the optimal arrangement by being creative and using some key techniques. 

Having excellent requirements is essential.  No, we are not promoting a major requirements gathering phase that results in a massive and meticulously detailed requirements document.  The requirements should be developed iteratively, in step with the development process.  Yet, developing the ability to write clear, meaningful requirements will help offset the gap between the product owner and the most remote members of your development team.  At Amplified Development, we are huge enthusiasts for Gherkin style requirements (aka Cucumber, SpecFlow, Behave, Behat, etc.).  Written properly, the Gherkin requirements are lucid and verifiable by the product owner, while also mapping unambiguously to automated tests.  Such requirements go a long way towards ensuring that the right features are being developed.

There are, however, always issues that need to be discussed.  And, even with excellent requirements, the developers’ understanding of the feature will often differ from the product owner.  So, you need to create as much interaction between the product owner and the remote team members as possible.  The following posts will consider some possible ways to do this:

• Daily meetings

• Iteration meetings

• Online project conversation

Extreme Remote = Off-shore?

In the previous post, I defined Extreme Remote as "having team members so far away that regular overlapping work periods are very difficult to maintain".  And, I referred to countries such as Pakistan and India as sources of technical talent.  So, isn't that just what we typically refer to as "off-shore development"? 

I consciously avoid using the term 'off-shore' because, to most people, it implies a way of working and a set of problems that is exactly what we are trying to avoid.  'Off-shore' typically implies a waterfall process and an 'over-the-wall' mentality.  With Extreme Remote, we want to apply genuinely agile principles and creatively solve/mitigate the challenges posed by distance, time-zones, and culture.

Here are some key differences between off-shore development and Extreme Remote teams:

Off-shore	Extreme Remote
Big Up Front Design	Iterative design
Requirement misunderstandings revealed at time of delivery	Requirements expressed as automated tests; continuous integration allows early evaluation and course correction
Lack of code ownership	In-house team members intimately familiar with code at all times
Code quality issues revealed at time of delivery	Daily code reviews and regular group code reviews preserve code quality continuously
Separate teams	Integrated team

The Case for Extreme Remote

Let’s start by accepting a well-established fact: 

The ideal environment for software development is a team physically co-located in the same room in close proximity to key stakeholders.  Nothing can replace the ambient knowledge, interpersonal dynamics, and streamlined access to stakeholders. 

So, why consider anything else?

The book Remote: Office Not Required by 37 Signals skillfully articulates the case for remote teams.  (It might be worth your while to get the book and read it before continuing.   At 256 pages, it’s a fairly quick read.)  Remote highlights the ability to access talent and to reduce overhead such as office space and commute costs.  Technology offsets many of the obstacles of remoteness via on-line chat, video conferences, screen sharing, etc.

One of the key tenets of Remote is:  Thou Shalt Overlap.  In other words, team members should make adjustments so that they are working at the same time for a few hours, ideally every day.

What if your team includes some remote members whose time zone makes it extremely difficult to overlap regularly?  If there is a 12 hour time difference, there is just no way to avoid having someone start very early or stay up very late in order to have some overlapping hours.  It is very challenging to maintain that sort of schedule day after day, over the course of a project.

For the sake of this discussion, let’s call that Extreme Remote: having team members so far away that regular overlapping work periods is very difficult to maintain. 

So, again, why would you ever consider such a team arrangement?

As with so many things in business:  Cost.

Consider the relative cost of living for developers in the Extreme Remote time zones (i.e. 10-14 hour time difference).  Here is a chart comparing several cities to Los Angeles (where I live and do most of my business).  

City*	Time difference**	Relative cost of living***
Almaty, Khazakstan	13 hours	-67%
Hyderabad, India	12 hours	-73%
Karachi, Pakistan	12 hours	-62%
Minsk, Belarus	10 hours	-71%
Nizny Novogorod, Russia	10 hours	-70%

* These are all cities where I have worked with skilled remote team members or are well known sources of technical talent.

** The time difference will vary through the year as daylight savings times start and end.

*** Cost of living comparisons are taken from www.expatistan.com.  Other sources may differ somewhat, but they still support the fundamental conclusion.

The cost advantage is clearly very compelling. Even after accounting for generous pay and various overhead costs, developers from these cities will cost less than half of what a developer of comparable talent in Los Angeles will cost.

So, the question really becomes:  How can we address the challenges of Extreme Remote teams sufficiently so that we can produce a high-quality product without losing the extraordinary value?  I will try to address this question in the next series of blog posts.