Research and Advances
Computing Applications Flexible and distributed software processes: old petunias in new bowls?


  1. Article
  2. References
  3. Authors
  4. Tables
  5. Sidebar: David Parnas
  6. Sidebar: Barry Boehm
  7. Sidebar: Giancarlo Succi
  8. Sidebar: Matthew Simons

Globalization and turbulent business environments are two factors that create significant challenges for software organizations today. In the wake of the IT downturn, many organizations have turned toward globally distributed software development (GSD) in their quest for the silver bullet of high-quality software delivered cheaply and quickly. At the same time, the increasingly volatile requirements in the business environment and the general trend toward leanness have led to a focus on more flexible, agile approaches as a potential solution.

Despite 50 years of software development experience, the perception of the so-called “software crisis” persists in many quarters, with continued instances of software projects exceeding budgets, and development schedules, and exhibiting poor levels of quality when completed—if completed at all. In recent years, agile methods have been proposed as a new, practice-led, paradigm that potentially addresses these problems by promoting communication, flexibility, innovation, and teamwork. Such methods differ significantly from the traditional plan-based approaches emphasizing development productivity rather than process rigor. Thus, they seek to accomplish only those development tasks that deliver business value quickly, while accommodating changing user requirements.

Practice is ahead of research in this area, and the use of agile approaches appears to be growing rapidly, but the fundamental underpinnings of agile methods need to be better conceptualized and theorized. However, agile methods are not the only result of the quest for flexible software processes. A similar aim can be found in the process tailoring and method engineering literature [3, 4, 7, 8]. Here, the focus is on adapting development processes to changing circumstances, albeit usually in the context of rigorous plan-based methods. Ironically, the suggestion by agile method advocates that agile methods must be applied in their entirety, as the benefits only arise through the synergistic combination of individual practices, is somewhat at odds with the spirit of flexibility, and not borne out in recent research that suggests agile methods should be flexibly tailored to the particular development context to achieve maximum effect [6].

Against this background, the software development environment is changing. The general trend toward globalization has particular implications for software development [2]. There are many potential benefits from GSD, including reduced development costs; reduced cycle time from follow-the-sun software development across multiple time zones; cross-site modularization of development work; access to a larger and better skilled developer pool; innovation and shared best practices; and closer proximity to customers.

However, as illustrated in the accompanying table, GSD also surfaces significant challenges in relation to communication, coordination, and control issues. While geographical distance by itself may induce a number of problems, increased geographical distance also often increases temporal distance and sociocultural distance. When people are not co-located they often must rely on asynchronous communication channels, such as email, and when working in different time zones, they cannot always expect to find the right person at the right time—an example of the emergence of a temporal distance. Similarly, when people from different countries and with different backgrounds collaborate, their frames of references, work habits, and language may differ, which can often lead to great frustration—an example of sociocultural distance. Interestingly, most GSD research seems to take the assumed benefits more or less for granted and focuses primarily on the problems associated with GSD. Our own ongoing research, on the other hand, indicates that many of the proclaimed benefits are simply not realized.

Although there is a steadily increasing body of literature on each of these two phenomena—process flexibility and agile methods on the one hand and GSD on the other—their combination is poorly understood, although expected to be beneficial. Interestingly, agile methods and GSD appear to be largely incommensurable. Due to physical separation of development teams in GSD, many of the key concepts within agile development, such as pair-programming, face-to-face interaction, and onsite customers, are difficult to apply. Also, given the risks inherent in GSD, the natural tendency is probably to favor plan-based approaches.

Given the complex nature of these topics, we solicited short commentaries from a number of domain experts to set the scene for this special section through a virtual panel debate. We begin with David Parnas, our distinguished colleague at the University of Limerick, who is more qualified than most to assess the relative merits of the issues at stake. He suggests, with healthy skepticism, that while agile methods may correctly diagnose the problems, they are not the right solution. He contends the problems associated with GSD are not significantly new and different from traditional software development problems. His message is that the root of the problem is poor documentation and poor understanding of the role of documentation. Agile methods that try to avoid documentation as far as possible is not the right way to go, he says.

Parnas’s piece certainly brings to mind the image of petunias in Douglas Adams’s The Hitchhiker’s Guide to the Galaxy: “Curiously enough, the only thing that went through the mind of the bowl of petunias as it fell was `Oh no, not again.'” To open up the debate, we asked another founding father of software engineering, Barry Boehm, to respond to Parnas’s comments. From his remarks, we gather it is, in fact, not a question of to document or not to document. Rather, it is a question of not falling into the trap of believing there is such a thing as a one-size-fits-all method. Obviously, this then brings us back to the question of tailoring. It appears agile methods per se may not be the answer to the required development process flexibility. It is how these methods are tailored and enacted that is central.

We also asked an academic with a specific interest in the area of agile methods, Giancarlo Succi (author of Extreme Programming Examined) to respond. Here, he invokes what he terms the Kantian categorical imperative of doing good and avoiding evil to characterize the debate. This is essentially the problem of means-ends inversion, whereby the endeavor to do good things, such as documentation, is always blindly followed to the expense of those real value-added development activities suited to the needs of the particular context.

To shed some light on the tailoring issue raised by both Boehm and Succi, we asked one of the leading practitioners in agile GSD to comment. Matthew Simons, Managing Director of ThoughtWorks India and a prolific writer on the topic, confirms that agile methods must indeed be tailored for GSD. As he describes here, their tailored story cards clearly illustrate the need for appropriate documentation, while still experiencing the benefits of agile development—even in a GSD context.

Unfortunately, and to the undoubted chagrin of all, we did not have the time and space to let these virtual panelists respond further to each other’s remarks. We expect this brief debate will stimulate some thoughts, and hopefully there will be a forum for continued discussion elsewhere.

In addition to these distinguished virtual panelists’ reflections on agility, flexibility, and globalization, we also solicited two types of research submissions: feature articles and commentaries. Having received more than 60 submissions, we are pleased to present the five pieces selected for publication after a comprehensive peer-review process.

Gwanhoo Lee, William DeLone, and Alberto Espinosa explore the tension between flexibility and rigor and suggests that successful GSD requires both agility/flexibility and rigor/discipline. They then derive a set of ambidextrous coping strategies to be used in GSD projects for achieving the required balance between the two extremes.

Balasubramaniam Ramesh, Lan Cao, Kannan Mohan, and Peng Xu focus on how distributed software development can be agile. The challenges to agile GSD they identify—communication, control, and trust—echo Parnas’ message about the importance of documentation. However, the strategy they suggest is more in line with the agile method sentiment and aims to create formal arenas for informal communication and knowledge sharing.

One-Ki (Daniel) Lee, Probir Banerjee, Kai Lim, Kuldeep Kumar, Jos van Hillegersberg, and Kwok Kee Wei consider how agility can be achieved in GSD projects by the proper alignment of IT strategy, IT infrastructure, and IT project management. The framework they present points out many important issues beyond those typically addressed by software process models and agile methods.

Clearly, achieving agility and flexibility in GSD is not only about software process management but also about business strategy and IT infrastructure: global business objectives are what should drive GSD, not specific development techniques or software engineering fads.

All three articles are based on solid case-based empirical research and as such reflect contemporary GSD practice quite well. Interestingly, they arrive at somewhat contradictory conclusions, for example, regarding the viability of achieving follow-the-sun software development. While Lee et al. found that minimization of task dependencies facilitated the implementation of follow-the-sun development, Ramesh et al. found this model to be far from reality in most cases. Although this latter conclusion accords with our own experience in the area, the inconclusiveness seems to indicate a need for further in-depth studies to understand this complex issue better in line with Carmel’s study of Infosys [5].

Flexibility and the ability to adapt to different circumstances are necessary for successful software development—be it globally distributed or not.

In their commentary, Patrick Wagstrom and James Herbsleb present an application that can be used to elicit source code dependencies, and based on those predict future communication needs between developers. As highlighted by our virtual panel debate and the three articles here, communication is indeed a key concern in software development, and is emphasized more than ever in the context of GSD and agile methods. The kind of tool presented is thus likely to play an increasingly important role in planning and managing GSD projects.

Nick Flor, author of the first academic paper on qualitative benefits of pair programming, explores the future of pair programming in the GSD context—remote pair programming. His commentary concludes by noting the seven properties that make traditional pair programming successful can also be achieved remotely with a proper cross-workspace information infrastructure.

The articles and commentaries in this special section provide a snapshot of an increasingly important area both theoretically and practically. Our virtual panel debate indicates we are dealing with what are largely subjective views and what works in one context may not work in another. In a sense this reinforces the whole idea of this special section: Flexibility and the ability to adapt to different circumstances are necessary for successful software development—be it globally distributed or not. The articles then go on to present a number of useful insights for how to achieve the required flexibility in GSD particularly.

Returning to Douglas Adams’s petunias, who having experiencing a few moments of existence, quickly concluded that it was all just a repetition of previous experience. Whether or not flexible and distributed software processes offer an improved future for software development or simply represent old petunias in new bowls is yet to be seen. However, the associated challenges addressed in this special section are real and increasingly important. We hope you enjoy reading this section as much as we enjoyed putting it together.

Back to Top

Back to Top

Back to Top


UT1 Table. Issues in GSD with examples of potential opportunities (+) and threats (-) [

Back to Top

Back to Top

Back to Top

Back to Top

    1. Ågerfalk, P.J., Fitzgerald, B., Holmström, H., Lings, B., Lundell, B., and Ó Conchúir, E. A framework for considering opportunities and threats in distributed software development. In Proceedings of the International Workshop on Distributed Software Development (Paris, Aug. 29, 2005). Austrian Computer Society, 47–61.

    2. Aspray, W., Mayadas, F., and Vardi, M.Y., Eds. Globalization and Offshoring of Software: A Report of the ACM Job Migration Task Force. ACM, 2006;

    3. Basili, V.R. and Rombach, H.D. Tailoring the software process to project goals and environments. In Proceedings of the 9th International Conference on Software Engineering. (Los Alamitos, CA, 1987). IEEE Computer Society Press, 345–357.

    4. Cameron, J. Configurable development processes. Commun. ACM 45, 4 (Apr. 2002), 72–77.

    5. Carmel. E. Building your information systems from the other side of the world: How Infosys manages time zone differences. MIS Q Executive 5, 1 (Mar. 2006), 43–53.

    6. Fitzgerald, B., Hartnett, G., and Conboy, K. Customising agile methods to software practices at Intel Shannon. European Journal of Information Systems 15, 2 (2006), 197–210.

    7. Fitzgerald, B., Russo, N.L., and O'Kane, T. Software development method tailoring at Motorola. Commun. ACM 46, 4 (Apr. 2003), 65–70.

    8. Kumar, K. and Welke, R.J. Methodology engineering: A proposal for situation specific methodology construction. Challenges and Strategies for Research in Systems Development. W.W. Cotterman and J.A. Senn, Eds. John Wiley, Washington, DC, 1992, 257–269.

Join the Discussion (0)

Become a Member or Sign In to Post a Comment

The Latest from CACM

Shape the Future of Computing

ACM encourages its members to take a direct hand in shaping the future of the association. There are more ways than ever to get involved.

Get Involved

Communications of the ACM (CACM) is now a fully Open Access publication.

By opening CACM to the world, we hope to increase engagement among the broader computer science community and encourage non-members to discover the rich resources ACM has to offer.

Learn More