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 four principles:
The main objective is the reduction of development duration / time to market.
Production sites are many time zones apart.
There is always one and only one site that owns and works on the project.
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. These 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]
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.
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.
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
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.
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.
1 2 3 4 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.
1 2 3 4 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.
1 2 3 4 5 Treinen, J. J., & Miller-Frost, S. L. (2006). Following the sun: Case studies in global software development. IBM Systems Journal, 45(4), 773-783.
1 2 Carmel, E. (1999). Global software teams: collaborating across borders and time zones. Prentice Hall PTR.
↑ 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.
↑ Yap, M. (2005, July). Follow the sun: distributed extreme programming development. In Agile Conference, 2005. Proceedings (pp. 218-224). IEEE.
↑ 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).
↑ Jalote, P., & Jain, G. (2006). Assigning tasks in a 24-h software development model. Journal of Systems and Software, 79(7), 904-911.
↑ 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.
↑ Sooraj, P., & Mohapatra, P. K. (2008). Modeling the 24-h software development process. Strategic Outsourcing: An International Journal, 1(2), 122-141.
↑ Taweel, A., & Brereton, P. (2006). Modelling software development across time zones. Information and Software Technology, 48(1), 1-11.
1 2 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.
The rational unified process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.
In software development, agile practices include requirements, discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s). Popularized in the 2001 Manifesto for Agile Software Development, these values and principles were derived from, and underpin, a broad range of software development frameworks, including Scrum and Kanban.
An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA). It represents a software architecture for distributed computing, and is a special variant of the more general client-server model, wherein any application may behave as server or client. ESB promotes agility and flexibility with regard to high-level protocol communication between applications. Its primary use is in enterprise application integration (EAI) of heterogeneous and complex service landscapes.
Open-source software development (OSSD) is the process by which open-source software, or similar software whose source code is publicly available, is developed by an open-source software project. These are software products available with its source code under an open-source license to study, change, and improve its design. Examples of some popular open-source software products are Mozilla Firefox, Google Chromium, Android, LibreOffice and the VLC media player.
Agile modeling (AM) is a methodology for modeling and documenting software systems based on best practices. It is a collection of values and principles that can be applied on an (agile) software development project. This methodology is more flexible than traditional modeling methods, making it a better fit in a fast-changing environment. It is part of the agile software development tool kit.
The incremental build model is a method of software development where the product is designed, implemented and tested incrementally until the product is finished. It involves both development and maintenance. The product is defined as finished when it satisfies all of its requirements. This model combines the elements of the waterfall model with the iterative philosophy of prototyping. According to the Project Management Institute, an incremental approach is an "adaptive development approach in which the deliverable is produced successively, adding functionality until the deliverable contains the necessary and sufficient capability to be considered complete."
Scrum is an agile team collaboration framework commonly used in software development and other industries.
The unified software development process or unified process is an iterative and incremental software development process framework. The best-known and extensively documented refinement of the unified process is the rational unified process (RUP). Other examples are OpenUP and agile unified process.
A stand-up meeting (stum) is a meeting in which attendees typically participate while standing. The discomfort of standing for long periods is intended to keep the meetings short.
Rational Rhapsody, a modeling environment based on UML, is a visual development environment for systems engineers and software developers creating real-time or embedded systems and software. Rational Rhapsody uses graphical models to generate software applications in various languages including C, C++, Ada, Java and C#.
Global information system is an information system which is developed and / or used in a global context. Some examples of GIS are SAP, The Global Learning Objects Brokered Exchange and other systems.
In software engineering, a software development process or software development life cycle (SDLC) is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.
A programming team is a team of people who develop or maintain computer software. They may be organised in numerous ways, but the egoless programming team and chief programmer team have been common structures.
DevOps is a methodology in the software development and IT industry. Used as a set of practices and tools, DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) as a means for improving and shortening the systems development life cycle.
Extreme programming (XP) is a software development methodology intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles, intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.
Disciplined agile delivery (DAD) is the software development portion of the Disciplined Agile Toolkit. DAD enables teams to make simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices espoused by advocates of agile software development, including scrum, agile modeling, lean software development, and others.
Communication in Distributed Software Development is an area of study that considers communication processes and their effects when applied to software development in a globally distributed development process. The importance of communication and coordination in software development is widely studied and organizational communication studies these implications at an organizational level. This also applies to a setting where teams and team members work in separate physical locations. The imposed distance introduces new challenges in communication, which is no longer a face to face process, and may also be subjected to other constraints such as teams in opposing time zones with a small overlap in working hours.
Distributed agile software development is a research area that considers the effects of applying the principles of agile software development to a globally distributed development setting, with the goal of overcoming challenges in projects which are geographically distributed.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
