Follow-the-sun


Follow the Sun, a sub-field of globally distributed software engineering, is a type of global knowledge workflow designed in order to reduce the time to market, in which the knowledge product is owned and advanced by a production site in one time zone and handed off at the end of their work day to the next production site that is several time zones west to continue that work. Ideally, the work days in these time zones overlap such that when one site ends their day, the next one starts.
FTS has the potential to significantly increase the total development time per day : with two sites the development time can increase to up to 16 hours, or up to 24 hours if there are three sites, reducing the development duration by as much as 67%.
It is not commonly practiced in industry and has few documented cases where it is applied successfully. This is likely because of its uncommon requirements, leading to a lack of knowledge on how to successfully apply FTS in practice.

History

Follow the Sun can be traced back to the mid-1990s where IBM had the first global software team which was specifically set up to take advantages of FTS. The team was spread out across five sites around the globe. Unfortunately, in this case FTS was unsuccessful because it was uncommon to hand off the software artifacts daily.
Two other cases of FTS at IBM have been documented by Treinen and Miller-Frost. The first team was spread out across a site in the United States and a site in Australia. FTS was successful for this team. The second team was spread out across a site in the United States and a site in India. In this case FTS was unsuccessful because of miscommunication, time zone issues and cultural differences.

Principles

FTS is based on the following four principles:
  1. The main objective is the reduction of development duration / time to market.
  2. Production sites are many time zones apart.
  3. There is always one and only one site that owns and works on the project.
  4. Handoffs are conducted daily at the end of each shift. The next production site is several time zones west.

    Common misconceptions

An important step in defining FTS is to disambiguate it from other globally distributed configurations to clearly state what FTS is not. The following four types of similar globally distributed configurations are not FTS:
FTS’s largest strength, spreading the development over multiple time zones, is simultaneously its largest weakness. Its distributed workflow is more complex to implement due to cultural and technical differences as well as the differences in time making coordination and communication challenging.
The main reason why FTS is difficult to implement is because the handoffs are an essential element that is hard to get right. The largest factor causing this difficulty is poor communication.
There are few documented cases of companies successfully applying FTS. Some companies have claimed to successfully implement FTS but these companies did not practice the daily handoffs. However, a limited amount of successful applications of FTS that did include daily handoffs of artefacts, using a distributed-concurrent model, were found by Cameron.
Recent studies on FTS have moved to mathematical modeling of FTS. The research is focused on the issue of speed and the issues around the handoffs.

Methods

As FTS is a sub-field of GDSE, the same agile software development methodologies that are found to work well in GDSE work well with FTS. In particular, Carmel et al. argue that agile software development methodologies assist the FTS principles because they:
  1. support daily handoffs. The continuous integration and automated integration of source code allows each site to work in their own code bases during their work day, while the integration maintains updated, testable code to be used by the next site.
  2. deal with communication. Agile methodologies emphasize communication. They specifically emphasize face-to-face communication, which can be done within one site. Since FTS aims to reduce inter-site communication, the face-to-face aspect is not a large hindrance to the overall application of agile development methodologies.
  3. elicit cooperation and collaboration. As FTS requires more collaboration and cooperation, this emphasis is especially useful.

    Challenges

Kroll et al. have researched papers published between 1990 and 2012 and found 36 best practices and 17 challenges for FTS. The challenges were grouped in three categories: coordination, communication and culture. These challenges should be overcome to implement FTS successfully.

Coordination

It is of great importance to select and adapt a methodology for the daily handoffs e.g. using agile software development or the waterfall model.
Identified best practices are the use of agile methods and using technologies to develop FTS activities. Agile supports daily handoffs which is a critical challenge in FTS. Management tools can be used to estimate and plan schedules, manage sprints and track progress. Additionally, technologies like conference video, emails and telephone calls are easy to implement and allow companies to perform synchronous and asynchronous communication between teams and works well in an agile environment.
Unfortunately, there is no solid best practice that works best since FTS can be applied in numerous ways.

Follow the Moon

A related concept is follow-the-moon, which is scheduling work to be performed specifically during local night-time hours for reasons such as saving on datacenter costs by using cheaper night-time electricity or spare processing power.

Other terms