Jump to content

Follow-the-sun

Add links
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Dawnseeker2000 (talk | contribs) at 18:39, 30 November 2020 (date format audit, minor formatting, typo(s) fixed: ’s → 's). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

World map showing part of it in the day and part at night; follow-the-sun workflow allows for continuous software work.

Follow the Sun (FTS), a sub-field of globally distributed software engineering (GDSE), 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.[1][2] 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 (as viewed from the perspective of a single time zone): 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.[3] 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.[4] 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.[3] 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:[2]

  • Global knowledge work is defined as geographically dispersed knowledge workers working collaboratively from multiple locations.[5] This is not FTS because there are no handoffs.
  • 24/7 service. In this configuration work is distributed to workers who are available at that time. It is focused on availability and the workers have little dependency, whereas FTS is focused on duration reductions and requires dependencies between the different sites in order to perform the daily handoffs.
  • 24-hour manufacturing. This configuration focuses on making shifts fully optimize expensive resources that could not produce more by increasing the number of employees per shift. However, this driver of reducing the resource cost is not the driver of FTS.
  • Collocated multi shifts. In contrast to FTS this configuration chooses one location where labor is cheap and runs multiple eight-hour shifts concurrently.

Difficulties

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.[3]

There are few documented cases of companies successfully applying FTS.[3] Some companies have claimed to successfully implement FTS but these companies did not practice the daily handoffs.[3][6] However, a limited amount of successful applications of FTS that did include daily handoffs of artefacts, using a distributed-concurrent model,[2] were found by Cameron.[7]

Recent studies on FTS have moved to mathematical modeling of FTS.[8][9][10][11][12] The research is focused on the issue of speed and the issues around the handoffs.

Methods

As FTS is a sub-field of GDSE,[4] the same agile software development methodologies that are found to work well in GDSE work well with FTS.[2] In particular, Carmel et al. (2009) argue that agile software development methodologies assist the FTS principles because they:[1]

  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. (2013) have researched papers published between 1990 and 2012 and found 36 best practices and 17 challenges for FTS.[13] The challenges were grouped in three categories: coordination, communication and culture. These challenges should be overcome to implement FTS successfully.

Coordination

  • Time zone differences reduce opportunities for real-time collaboration. Team members have to be flexible to achieve overlap with remote colleagues. The limited overlap and the delay in responses have a negative impact on the coordination.
  • Daily handoff cycles or handing off work-in-progress are a requirement of FTS because without it the time to market cannot be decreased.
  • Geographical dispersion
  • Cost estimation
  • Loss of teamness
  • Number of sites
  • Coordination breakdown
  • Managerial difficulties
  • Technical platforms

Communication

  • Loss of communication richness / face-to-face communication
  • Social cultural diversity difficulties
  • Synchronous communication
  • Language difference
  • Technical difficulties
  • Manage religious or national holidays.

Culture

  • Cultural differences
  • Different technical backgrounds

Best practices

It is of great importance to select and adapt a methodology for the daily handoffs[1][13] 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.[1] 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[14] or spare processing power.

Other terms

  • 24-hour development
  • round-the-clock-development

See also

Notes and references

  1. ^ a b c d Carmel, E., Dubinsky, Y., & Espinosa, A. (2009, January). Follow the sun software development: New perspectives, conceptual foundation, and exploratory field study. In System Sciences, 2009. HICSS'09. 42nd Hawaii International Conference on (pp. 1-9). IEEE.
  2. ^ a b c d Carmel, E., Espinosa, J. A., & Dubinsky, Y. (2010). " Follow the Sun" Workflow in Global Software Development. Journal of Management Information Systems, 27(1), 17-38.
  3. ^ a b c d e Treinen, J. J., & Miller-Frost, S. L. (2006). Following the sun: Case studies in global software development. IBM Systems Journal, 45(4), 773-783.
  4. ^ a b Carmel, E. (1999). Global software teams: collaborating across borders and time zones. Prentice Hall PTR.
  5. ^ Espinosa, J. A., Cummings, J. N., Wilson, J. M., & Pearce, B. M. (2003). Team boundary issues across multiple global firms. Journal of Management Information Systems, 19(4), 157-190.
  6. ^ Yap, M. (2005, July). Follow the sun: distributed extreme programming development. In Agile Conference, 2005. Proceedings (pp. 218-224). IEEE.
  7. ^ Alexander Cameron (August 2003). "Rational Users Conference 2003. Reducing Time-To-Market Using Follow-the-Sun Techniques".
  8. ^ Espinosa, J. A., & Carmel, E. (2003, May). Modeling coordination costs due to time separation in global software teams. In Global Software Development Workshop, International Conference on Software Engineering (ICSE) (pp. 64-68).
  9. ^ Jalote, P., & Jain, G. (2006). Assigning tasks in a 24-h software development model. Journal of Systems and Software, 79(7), 904-911.
  10. ^ Setamanit, S. O., Wakeland, W., & Raffo, D. (2007). Using simulation to evaluate global software development task allocation strategies. Software Process: Improvement and Practice, 12(5), 491-503.
  11. ^ Sooraj, P., & Mohapatra, P. K. (2008). Modeling the 24-h software development process. Strategic Outsourcing: An International Journal, 1(2), 122-141.
  12. ^ Taweel, A., & Brereton, P. (2006). Modelling software development across time zones. Information and Software Technology, 48(1), 1-11.
  13. ^ a b Kroll, J., Hashmi, S. I., Richardson, I., & Audy, J. L. (2013, August). A systematic literature review of best practices and challenges in follow-the-sun software development. In Global Software Engineering Workshops (ICGSEW), 2013 IEEE 8th International Conference on (pp. 18-23). IEEE.
  14. ^ Jeff Caruso (19 August 2009). "Follow the moon, and save millions".
Retrieved from "https://en.wikipedia.org/w/index.php?title=Follow-the-sun&oldid=991563061"