"Social distancing" responses to COVID-19 have ordered people to work from home wherever possible. No doubt this includes many software developers, who might ordinarily be conducting daily stand-up meetings and other forms of face-to-face communication called for by modern software development processes. Obviously the stand-up meeting could be replaced by a videoconference, say, and tools like JIRA, Git, and the like have been on-line from the get-go. But what does research say about developing software without being in the same location as your co-workers?
Firstly, software developers aren’t the only kind of professional who sometimes work from home, and there’s a large body of literature describing professionals in various sorts of flexible work arrangements including remote work. One interesting observation that appears in several literature reviews is that the great majority of studies of flexible working arrangements focus on the experience of the flexible workers (who generally report positive experiences) rather than on their colleagues (who often report negative experiences). It might be convenient for the flexible worker to collect children from school or schedule doctor’s appointments during the week, for example, but it can be frustrating for colleagues who need that worker’s input to keep the project rolling along.
Lynn van Dyne and colleagues (2008) present the following tips for teams containing flexible workers, synthesised from studies undertaken in the early 2000’s:
- manage your time as a team rather than have it dictated by a manager and, as much as possible, synchronise team members’ availability so that everyone is available at some common times;
- re-define work contributions in terms of tasks completed, participation in “interaction rituals” (daily stand-ups, say), and so on, rather than time spent in the office; and
- make yourself available pro-actively, such as by anticipating work to be done and initiating contact with co-workers.
Pamela Lirio and colleagues (2008) add some tips specifically for managers of professionals working part-time, some of which are applicable for remote working as well, based on interviews with part-time professionals and their managers in North America:
- pro-actively find or create arrangements for reduced working hours;
- trust employees to do their work without micro-managing; and
- continue to support the on-going development of workers on reduced hours.
Software developers in particular can draw on the experience of two well-established modes of software development in which remote working is common: global software development and open source development.
Global software development refers to software developed by teams located around the world, as might occur in large multi-campus companies like Google and Microsoft. Even though there are obvious challenges in implementing methods like Scrum when some software developers are in Australia and others are in North America, it’s hard to find literature describing global software development being carried out any other way. Baturub Rizvi and colleagues (2015) identified the following strategies in a review of the literature published between 2007 and 2012:
- establish a strong communications infrastructure with many kinds of communication channels;
- encourage developers to actually use these channels in both formal and informal settings;
- establish a formal communication strategy for exchanging information after relevant events; and
- ensure that developers working in different timezones have some overlapping work hours in which teleconferences can be scheduled.
Open source software development often proceeds without any central office at all. Most of the published studies of open source processes are around a decade old, but they agree that (at least back then) there was no single widely-accepted process. Some researchers have tried replacing daily meetings with on-line reporting tools that prompt developers to register their progress and any obstacles that they are facing at regular intervals (Kanban-like tools are one option); Luigi Lavazza and colleagues (2010) and Phillipp Diebold and colleagues (2013) both report that this method could work as well as face-to-face methods in their trials.
Finally, agile practices encourage software developers to work closely not just with each other, but with their clients. I’m not aware of any studies specifically addressing this issue, but aside from obvious suggestions to communicate by phone, e-mail and teleconferencing, software developers may have the option share a prototype that lets clients know how development is going and give them the opportunity to provide provide feedback.
References
Philipp Diebold, Constanza Lampasona and Davide Taibi 2013. Moonlighting Scrum: An Agile Method for Distributed Teams with Part-Time Developers Working during Non-Overlapping Hours. Eighth International Conference on Software Engineering and Advances, pages 318-323.
Luigi Lavazza, Sandro Morasca, Davide Taibi and Davide Tosi 2010. Applying SCRUM in an OSS Development Process: An Empirical Evaluation. International Conference on Agile Software Development, pages 147-159.
Pamela Lirio, Mary Dean Lee, Margaret L. Williams, Leslie K. Haugan and Ellen Ernst Kossek 2008. The Inclusion Challenge With Reduced-Load Professionals: the Role of the Manager. Human Resource Management 47(3), pages 443-461.
Buturab Rizvi, Ebrahim Bagheri and Dragan Gasevic 2015. A Systematic Review of Distributed Agile Software Engineering. Journal of Software: Evolution and Process 27(10).
Linn van Dyne, Ellen Kossek and Sharon Lobel 2007. Less Need to Be There: Cross-level Effects of Work Practices That Support Work-Life Flexibility and Enhance Group Processes and Group-Level OCB. Human Relations 60(8), pages 1123-1154.