Follow the Sun Paper for Keystone Conference Printed on 10/2/2018 Page 1 of 21

Follow The Sun paper for Keystone conference printed on 10/2/2018 Page 1 of 21

“Follow The Sun” Workflow In Global Software Development: Theory, Modeling And Quasi-Experiment To Explore Its Feasibility

Erran Carmel, Yael Dubinsky, and J. Mark Johnston

Erran Carmel,Univ. of Maryland, Univ. Coll.

Yael DubinskyIBM Haifa Research LabIsrael

corresponding author: Erran Carmel

submitted on Dec 17 2008 to -

The Impacts of Global IS Sourcing on Engineering, Technology and Innovation Management

22-25 March 2009

Keystone, CO, USA

Keywords:

Follow the Sun

24-hour development

Quasi-experiment

Time to market

Global software development

“Follow The Sun” Workflow In Global Software Development: Theory, Modeling And Quasi-Experiment To Explore Its Feasibility

Abstract

Follow The Sun (FTS) is a special case of global software development. It is a special case in that there is a hand-off of unfinished work every day from one development site to the next -- many time zones away. This is markedly different from the majority of global technology work / offshoring in which coordination is necessary, but rarely at the level of absolute dependency on a daily basis.

The objective of FTS is reduction in development duration (also known as time-to-market reduction, or cycle-time reduction). Time-to-market is most important in industries where products become outmoded quickly,

Unfortunately, there have been relatively few successful cases of FTS in the field due to coordination difficulties. The first global software team specifically established to take advantage of FTS was at IBM in the mid-1990s. However, FTS was difficult to achieve and managers quickly resorted to traditional forms of offshoring to capitalize, instead, on wage differentials.

In this article we present a foundation for understanding FTS including: a definition, a description of its place in the life cycle, a discussion of choice of methodologies that are likely to make it successful.

We describea multi-method approach to the study of FTS and present our findings from modeling and from quasi-experiments.

First we present and develop a mathematical model of FTS benefits. The data suggest that unless the hand-off efficiencies are high then the duration reduction payoff for a third and fourth site of FTS is relatively small.

We also present the outcomes of a set of exploratory quasi-experiments designed to test FTS and measure the speed of software work. The experiments were conducted with software engineering students performing semester projects. The FTS teams completed their work in similar or better duration relative to the control teams. This is in contrast to previous studies in which the software work of distributed teams takes longer in duration relative to co-located teams. We suggest that this happened-- in our case-- because of Agile implementation-- specifically the tight iteration and deadlines involved.

Introduction

Follow the Sun (FTS from hereon) is a rather intuitive idea: Hand-off work every day from one site to the next as the world turns (for example, USA to India). The impact is theoretically profound. One can reduce the development duration by 50% if there are two sites and by 67% if there are three sites. In spite of these tempting numbers, FTS has had few industry success cases and there has been little academic research into FTS. This article fills that void by presenting a multi-method examination of FTS.

FTS (also called: 24-hour development and round-the-clock development) is a subset of global software development and shares with global software development the many issues and challenges of coordination, culture, and communication. However, in our understanding of FTS, it is uniquely focused on speed in that the project team configuration is designed to reduce cycle-time (also known as time-to-market reduction, or duration reduction). We position our study as a foundation for studying the acceleration of software work in order to reduce time to market.

Multi-method research strategy to investigate FTS

Given the paucity of knowledge in both theory and practice, we have designed a multimethod research program to study FTS. In this paper we describe our first steps using methodologies #1 and #2 and in the future we plan to make use of the latter two. Our multi-method approach highlights areas that a single method can reveal relatively little about.

Modeling. Develop research frameworks for time separation and create mathematical and simulation models to better understand how to optimally architect FTS and how to evaluate its costs and benefits.
Quasi-experiments allow for refinement of research techniques and present lessons for practical FTS techniques.
Controlled lab experiments. See, for example, similar research in [15].
Field-study of FTS. Highlight and learn from successes and failures in industry. We caution that there are very few of these.

Why is time-to-market important?

FTS is enticing to business in order to achieve time-to-market reduction.[1]Time-to-market is the length of time it takes from a product conception until the product is available for use or sale [30]. Figure 1 depicts this construct. Time-to-market is most important in industries where products become outmoded quickly, such as, these days, mobile telephone handsets. Therefore time-to-market is critical for handset software. Time-to-market is also important for strategic information systems such as competitive e-commerce systems or innovative Supply Chain Management systems. There can be other considerations in producing systems more quickly such as avoiding contract creep.

Figure 1. Timeline of time-to-market, measured from inception to use/sale

A desire for rapid development -- a sense of urgency -- is shared by most firms and projects in a competitive marketplace, But most efforts to reduce project duration are reactive: hurry-up tactics, such as overtime; work speed-up; setting aggressive deadlines; and adding personnel. Hurry-up, speeding up, or "stepping on the gas," means doing what needs to be done -- only faster. This is generally not recommended because of fatigue [26]. Adding personnel is of little interest in software because of the wisdom gained from the seminal Brooks' Law [3] ("adding manpower to a late software project makes it later").

FTS represents a globally dispersed proactive way to reduce time-to-market. It is centered on a high awareness of achieving this goal[30]by rethinking development processes. In summary, time-to-market reduction achieved by using FTS requires a deliberate design around the objective of speed.

Time-to-market is an important area of inquiry because it is relatively understudied in the disciplines of MIS and software engineering. In software engineering/ global software development there has been some tangential interest such as [19] where multi-site software teams took longer than in co-located teams. Meanwhile, our Management Information Systems (MIS) literature has devoted some attention to investigating the time domain but has largely focused on subjective perceptions of time [29] rather than approaches to increasing speed.

Why is FTS so difficult in practice?

Globally distributed development adds difficulties to productive work. The frenetic pace of development will tend to pull apart teams by Carmel’s [7] five centrifugal forces of global software teams: loss of communication richness, coordination breakdown, loss of ‘teamness’, cultural differences, and geographic dispersion.

FTS is even more difficult and quite uncommon because the production teams are sequentially handing off work-in-progress (unfinished objects). The production objects require daily “packaging” so that the task is understood by the next production site without synchronous interaction.

There are times when the next production site needs more information and cannot proceed fully without clarification. When clarification is required then an entire day may be wasted because the previous site has already gone home. Sometimes a misunderstanding leads to re-work (classified vulnerability cost[14]).

FTS literature

The first global software team specifically set-up to take advantage of FTS was at IBM in the mid-1990s and is documented extensively in [7]. This team was set up from inception to work in FTS. It was spread out in 5 sites across the globe. However, FTS was unsuccessful. It was uncommon to move the software artifacts daily as had been hoped. Since FTS was not working the managers gave up on that objective though they continued global distributed software development.

We note that some have claimed successful FTS, but on closer inspection, while these projects were indeed dispersed, they did not practice FTS [35][34]. Cameron [4] has claimed some limited success at FTS at the global American firm EDS (now HP). Hawryszkiewycz & Gorton were the first to examine FTS in a series of small controlled experiments in the 1990s [16]-- though they did not continue their line of inquiry. In recent years others have written about the promise and failures of FTS [17][18][11][2]. Contrary to myth, Indian offshore firms do little, if any, FTS[8].

With rather limited progress in the last decade, recent FTS literature has moved in another interesting trajectory: mathematical modeling of FTS [13][24][31][32][33]. We will survey to two week each one of these papers in the next section. It is worthwhile noting at the outset the each of these studies uses somewhat different approaches and assumptions. All of them focus, to some extent, on the issue of speed, while making critical assumptions that deal with the hand-over and coordination issues.

Figure 2. FTS compared to other globally distributed configurations.

The common globally distributed configurations involve decomposing tasks by expertise, by product (or subproduct or module), and by phase (see Figure 2)[7][19]. While central to FTS is the sequential hand-off of work from one site to the next, paradoxically the vast majority of global teams do the utmost to do the exact opposite - to reduce the number of hand-offs as much as possible. Note that the other three approaches attempt to minimize hand-offs.

FTS definition

In light of the above, we propose a formal definition of FTS. We claim that software development FTS means satisfying all 4 of these criteria:

Production sites are far apart in time zones.
One of the main objectives is duration reduction/ time-to-market reduction.
At every point of time there is only one site that owns the product. (We must specify this criterion in order to make the dependency unambiguous).
Hand-offs are conducted daily, where a hand-off is defined as a check-in of a work unit that the next site is dependent upon in order to continue. (We specify this in order to make the dependency unambiguous).

Therefore, FTS is defined as:

A type of global knowledge workflow, designed in order to reduce project duration, in which the knowledge product is owned and evolved by a production site and is handed-off daily to the next production site that is many time-zones apart to continue that work.

We also state one key assumption and several other points. The key assumption is that each production site works during their day because most people around the world tend to work during the day and sleep at night. Related to this is an assumption that each production site works as a team and coordinates inside the team.

Some other foundational points and assumptions:

In software work there is one common repository. This allows all sites to “commit” the code/objects at the end of the workday.
Exception condition: the unit of work can be sometimes = zero, in cases of holidays etc. While work is usually passed on daily, this cannot happen for every team every day.
A team can consist of one or more members.
Since Time To Market is a major goal then it is measured using objective units and possibly benchmarked.

Our definition is consistent with other, broader definitions of global software development. For example, it assumes full cooperation between production sites, as defined by[21].

Our careful definition allows us to expand our thinking of FTS. We can all envision FTS with 2 or 3 sites. Assuming 6 hours of intensive software development per day, it is possible to do FTS with even 4 sites spread out across time zones of the globe. It may even be beneficial. We assume that each team will work intensively for 6 hours and during the beginning and end of day will perform other admin/work tasks.

FTS is the least common of the four global work configurations. Partially because of its rarity, we have noticed confusion about FTS in industry and we can correct it with our definition. The two most common misconceptions are that FTS is:

Global knowledge work in which knowledge workers are working and coordinating around the world. However in most cases these knowledge workers have little dependency and do not pass on work in order to reduce duration. Global knowledge work only satisfies criterion #1. Therefore this is not FTS.
24h work/ shift work (3 shifts a day). For example, a call center system routes calls to workers as the earth revolves. However in most cases these knowledge workers have little dependency with each other and do not pass on work in order to reduce duration. Shift work only satisfies criterion #1 and #3. WhomTherefore this is not FTS.

What methodology is best for FTS?

Those who have examined FTS closely have recognized the importance of selecting and adapting a software development methodology for the special needs of daily hand-offs. FTS requires very careful considerations of methodology and process. Cameron at EDS crafted a special methodological adaptation [4]. Similarly, IBM’s classic FTS team of the 1990s constructed a unique organization structure and process [7].

Some practitioners have told us that waterfall-like approaches seem best for FTS. Others have proposed other iterative models. We examine each of these.

Let’s begin by examining the generic software development lifecycle (SDLC) phases. While some phases can work easily for FTS, at least over short periods (see Figure 3), others do not. Testing has worked well in FTS for many companies. One team searches for bugs, documents these in the bug database, which is then accessed and worked on by the software team at another site many time-zones west. Testing works well with FTS because the hand-off is structured, granular-- and with trained staff-- will usually not suffer from miscommunications. Prototyping is another specific phase that suits FTS.

Figure 3. Generic waterfall SDLC.
Notation above the arrows points to specific phases that are a good fit for FTS

The work peculiarities in each of these phases mean that the theoretical advantages of FTS (reducing time-to-market by 50%), tend to show up in isolated phases. If one manages to perform FTS in one specific phase, it does not mean that those techniques are transferable to the other phases. Thus, if only testing used FTS successfully then overall project duration is reduced by only 12.5% rather than the ideal 50% (see Figure 4).

Figure 4. Typical percent of project schedule duration in each SDLC stage

We considered several iterative development methods such as RUP and Agile[1][20] and selected the Agile approach as most promising for FTS. We note that other iterative approaches can handle daily hand-offs, e.g., RUP and specifically Agile RUP.Later, we describe our first FTS exploratory quasi-experiments using an Agile approach.

There has been some research on synthesis of distributed global teams and the Agile approach [e.g., [11][36]]. In the case of FTS, examining the SDLC when using the Agile approach shows that in every agile iteration all software development activities (define, design, code, test, integration) are performed for a smaller scope which is usually feature-based (conceptually described in [1][[20]]). The iteration length varies from two weeks to four weeks depending on the specific agile method that is used. We argue that in FTS agile environment, testing of small portions along the way should lead to a duration reduction of at least 12.5% relative to waterfall-like approaches and possibly more if we take into account the accumulative effect of testing on the development process and software quality (stability, maintainability, etc.).

The Agile approach has a keycharacteristics that assists in structuring FTS settings:Support daily hand-offs. Continuously integrating using an automated integration environment enables each team to develop in its own code-base in its own time period. Yet, each team maintains an updated testable code base to be used by the next production site. The policy of keeping the integration green (all test pass) at the end of the work day is common in Agile teams and nicely fits with FTS requirements.

In summary, we note that once we move beyond broad generalities about researching FTS we must make choices regarding configuration and methodology. In our research we try to remain neutral to the extent possible and when wechoose configurations and methodologies and we try to make these clear. In the case of our theoretical FTS model, our model was largely neutral to configurations and methodologies. In the case of our FTS quasi-experiment -- this is based on agile programming approaches.

Research Method #1: Modeling

The research of FTS lends itself to modeling because of the intensive workflow nature of the problem domain. Modeling (and its close cousin simulation) is a research method that enables us to surface trade-offs and investigate different design configurations; furthermore, modeling allows the investigation of feasibility. As we shall see here, a basic model of FTS quickly surfaces the difficulties in harvesting its benefits. Researchers have begun to model FTS only recently, so at the end of this section we summarize and compare similar research efforts by others. There are several ways to define how efficient production and operations are, and so far FTS investigators have used many of them. Our key contribution is that our model standardizes the language describing duration, cost, and quality by using non-dimensional parameters.