Extreme Remote: Product Management - Online conversations

Since the product owner is not within hearing distance of the remote team members (or not even awake when they are discussing issues), you absolutely must create a vibrant and effective online conversation.  Many tools such as HipChat and Slack support group chats.  Make this the primary way that issues get discussed.  And, have questions for the product owner clearly labeled so that they can focus on the product issues rather than all of the other technical discussions.

Extreme Remote: Product Management - Iteration Meetings

During the iteration cycle, there are some key meetings you can strongly encourage product owners to attend. 

Feature overview (aka ‘Story time’) – In advance of an iteration, you may wish to have a business-oriented overview of a system feature.  This is a great opportunity to have the product owner describe how an associated facet of the business works.  Many misunderstandings get pre-empted when developers can picture the business context.

Iteration planning – Early in iteration planning, you can review the requirements and any mockups.  The product owner may identify a misunderstanding that can be corrected before development begins.

Iteration review – The product owner should certainly be part of the iteration review, if at all possible.  Here is where any misunderstandings become plain to see.  If the product owner identifies course corrections at the end of every iteration, they can be implemented quickly and efficiently in the next iteration, keeping the project from straying off-course.

Note:  Product owner involvement in iteration meetings becomes even more meaningful when iterations are kept short.  Ideally, one week is best since it allows course correction very often.

For these iteration meetings, you may be able to request some extra flexibility from the remote team members.  Could they come in very early or be available late so that the product owner can meet at a more convenient time?  Depending of the product owner and the company culture, that may be important.

Extreme Remote: Product Management - Daily Meetings

Likely, to keep the team connected, there will be some form of daily meeting.  But, it is likely to be at odd hours that may not be convenient for product owners.  Don’t hesitate to invite them, though.  You may be surprised at what is possible.

On one project, we managed to have two executive stakeholders on a 9:30pm nightly online meeting with the remote team members.  Nice participation if you can get it!  Realistically, I don’t ever enter into a project expecting that level of product owner involvement.  But, take as much interaction as you can get!

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.