Essec Business School

The Covid-19 crisis that has hit the world in 2020 has affected workers in two markedly distinct ways. On the one hand, professionals in the most critical roles—including medical professionals and caregivers, emergency service providers, or those working in food and agricultural sectors—continue to go to work on a daily basis. This has resulted in a renewed recognition of their societal contribution, which will hopefully survive the crisis. On the other hand, a large part of the working population has to work in their home office. Even though this may be a comfortable situation for many compared to the struggles of front-line workers, this situation is not without challenges. Even beyond more critical challenges related to social justice and family life, important questions emerge as to whether working from home actually works.

One profession that is worth looking at more closely is software development. Software development has never been more relevant, given our digital age and especially in times where human experiences and professional and social exchanges often exclusively rely on digital technologies (Yoo, 2010). At first glance, we may be tempted to think that the impact of working from home is less dramatic for software developers. Coding can be done everywhere. The tech-savvy software developers should not have a problem with using collaboration tools. Many practices in modern software development are inspired by the way open-source communities work. So as long as GitHub is working, we should be fine, right?

Of course, there is some truth to this. Software development is one of the activities that can be done (and regularly is done) in a distributed way. But there are caveats as well. Software developers forced to work at home will have the exact same personal challenges during such exceptional times than everybody else does. But there are also work-related intricacies that software development teams have to deal with, particularly those that follow an agile software development approach. These disruptions come in the form of challenges related to the software product, the development process, and social aspects of the team.

The challenges of agile software development from home

First, there are challenges related to the software product itself and its architecture. Software architecture is the fundamental structure of a software system and describes how the system is split up into components and how these components interact with each other. Systems can be more or less modular, which has direct implications for the extent of communication and coordination that is necessary within and across development teams. Teams working on modular systems should find it easier to adjust to a work-from-home situation. However, contemporary agile software development strives to be adaptive and lean, which often means that architectural decisions are postponed as much as possible. Such postponement of architectural decisions leads to architectures that are, to some extent, emergent. This has certain benefits in normal times but may be less adequate in a work-from-home situation as it requires more intensive coordination. In fact, platform structures, which prescribe an extensible basis in advance based on which agile teams can work rather independently, may be a better fit.

Second, challenges in times of forced work-from-home may relate to the process of software development. One of the key tenets of agile software development is its focus on iterative and collaborative work. Team members have shared code ownership, meet regularly, and follow collaborative practices, as prescribed by methods such as Scrum or Extreme Programming. For example, a common practice that agile teams follow is pair programming, where two developers jointly develop code (Kude et al., 2019). One goal of pair programming is to ensure instant quality control. As opposed to the high-touch approach of pair programming, teams may also rely on low-touch, high-tech solutions for quality assurance, such as automated testing. Pair programming extends beyond quality control as it helps create the positive teamwork structures and behaviors that are desperately needed in exceptional times (Kude et al., 2019). Yet, when primarily aiming for quality assurance, one can easily assume that low-touch approaches such as automated testing work more reliably than high-touch approaches. The collaborative and iterative approach of agile development also extends to clients and end-users, who are regularly involved in the development activities early on and on a continuous basis. This can be a problem in times of a crisis like the current one because client feedback may not be available if users or client organizations are not working normally.

Third, the social fabric of a team may experience challenges. Many of the immediate communication and coordination needs can indeed be done via communication tools when teams have to shift to working from home. In particular, teams that are used to distributed work may find it relatively easy to switch to a work-from-home setting, and this may work well in the short run if the challenges discussed above can be addressed. However, if teams are accustomed to exchanging on-site at least sometimes, the fully distributed set-up may become more problematic over time. In fact, while explicit communication may relate to quick task-related interactions that can be done online, a lot happens between the lines. Research tells us that teamwork factors, such as psychological safety or shared understanding (Edmondson 1999; Kude 2019), are a cornerstone of functioning software development teams. In teams where members trust each other and feel safe to speak up (in other words, teams where psychological safety is present), the fail-fast-learn-fast culture of agile approaches may work very well and make teams stronger. In teams that lack psychological safety, team members are at risk of interpreting often direct and sometimes harsh feedback the wrong way. In work-from-home settings, misunderstandings and perceived inadequate criticism may pile up and deteriorate the precious remaining trust. This is less likely to happen in teams with shared understanding about each other, the development process, and the final software product. Shared understanding needs to be nurtured, however, and it may get obsolete quickly as circumstances change. Nurturing the team’s shared understanding may be tricky in crisis mode.

Developing from home in practice

The example of one French media and advertisement company illustrates the relevance of these challenges. At this organization, the norm for the software development teams was to work on-site. In fact, team members would sit physically close to each other, making communication very instantaneous and immediate. I had a first conversation with the technical lead and Scrum master (a key role in Scrum teams that facilitates the Scrum approach) of one of the company’s development teams shortly after the forced work-from-home situation had started. At that time, the situation seemed mostly under control and the sudden work-from-home context seemed less problematic. In fact, the main problem seemed to be that developers had difficulties setting up the remote connections to the servers. Before the crisis, the company had been rather conservative when it comes to remote work and home office culture due to concerns about security. As a result, the technical infrastructure needed to be set up first to actually be able to work from home. Once this problem was solved, everything seemed to go into the right direction. 

However, the two subsequent conversations a few weeks into the lockdown revealed new and unexpected challenges. First, again with regard to the software development process, it turned out that the firm-internal end-users for which the team was developing a specific solution were not available for feedback. Given that the solution was to be used “in the field,” there was no way to evaluate prototypes in real-life settings, thus thwarting the rapid prototyping approach the team usually follows. Second, two fundamental challenges emerged with regard to product architecture. On one hand, the interviewee reported a rather critical issue of cross-team coordination. The team made an update to a component that was also used by another team. The team had sent a short message to the other team, who responded positively. But, likely due to the challenging circumstances, the other team had not realized the wider consequences of this change. As a result, the other team struggled with the loss of important data and resolving the issue required major coordination efforts. The interviewee explained that in normal times, the teams would have had more discussions about this change and its implications, and “not just a chat message. You can’t explain such a complexity in just one sentence…The thing is, the guy is just in front of us [normally].” 

On the other hand, given the lack of opportunities for ad-hoc communication, coordination was relegated to formal meetings. When one specific question regarding a new feature required additional coordination, the product owner of the team approached one developer directly and coordinated activities in a one-on-one fashion—as opposed to raising the issue in one of the team meetings, which would have created awareness in the entire team. The product owner may have pushed more than usual for this new feature, given that the future of the project was unclear in light of the current crisis and the product owner was working toward producing quick results. In situations like these, it may sometimes be difficult to predict what changes to the code are relevant for the rest of the team. In fact, fostering awareness and shared understanding among team members is one strength of agile software development in collocated settings. For this team, the change resulted in cascading coordination challenges that temporarily affected the flow of the team.

What will happen to software development teams when the crisis is over?

What medium- and long-term effects will the current situation have on software development teams? Which teams will handle the situation particularly well? What is going to happen once teams come back to the office and develop software on-site again? 

Although these are open questions that need more research, what will likely be the case for organizations at large can also be expected for software development teams: The current crisis is likely going to widen the gap between teams that function well and those that don’t. Many teams may struggle now, but those that had not been doing well before the crisis will probably struggle even more after the crisis. By contrast, those teams that worked well before the crisis might be able to even benefit and come back even stronger. 

Teams that have been struggling before the crisis, in terms of both technical and social aspects of teamwork, may suffer even more when coming back. They may somehow make it through the forced work-from-home period. But the crisis mode may take its toll in the aftermath. Teams that don’t work well will already have a harder time during the current crisis as they lack appropriate architectures and processes and lack critical teamwork factors. But these teams may struggle even more once the immediate health crisis is overcome and teams go back to work on-site. During the crisis, communication may be reduced to the minimum to keep going. This may mean that formal procedures and architectural decisions may be bypassed to achieve short-terms goals, taking the path of the least resistance. During the forced work-from-home phase, looming conflicts may escalate, further aggravating teamwork. The more likely scenario, however, is that disagreements that should have been brought to the table are suppressed, which will likely backfire in the future through reemerging conflicts. Thus, while working from home, teams that don’t work well may not only build “technical debt,” in terms of technical obligations that need to be addressed later on (Ramasubbu and Kemerer 2016), but also “social debt,” which refers to the future consequences of decisions related to people and their interactions (Tamburri et al. 2015).

The aftermath of the crisis will likely play out differently for teams that function well, i.e., those that work based on architecture and development processes that balance stability and flexibility and those that have developed sound teamwork structures and behaviors, e.g., by successfully developing team psychological safety and high levels of shared understanding. Those teams may in fact be able to leverage the special circumstances and take the opportunities associated with it. As individuals, most of us have experienced how facing the situation of a pandemic has implications for our personal life and well-being. Individuals may or may not easily find suitable personal strategies for handling the crisis. In any case, such an extreme situation may very well shift priorities and let individuals refocus on the presence and on the essential aspects of life that are truly important for them. Such increases in mindfulness may actually also be possible for software development teams: software development teams may strengthen their “team mindfulness” (Yu and Zellmer-Bruhn 2018, Liu et al. 2020) which has been defined as the “shared belief among team members that their interactions are characterized by awareness and attention to present events, and experiential, nonjudgmental processing of within-team experiences” (Yu and Zellmer-Bruhn 2018, p. 324). Teams that made it in good shape through the crisis may have the resources afterwards to apply their learnings and reassess their routines, development processes, tool support, and architecture. In doing so, their functioning teamwork structures and behaviors will likely be of great help. Also, teams that function well will have realized that they can count on their trusted relationships and their shared mental models and that these teamwork factors help them navigate through uncertain and challenging times. This will help teams to be even more mindful about these teamwork factors and continue to cherish and develop them.

Summing up, interesting effects can be expected for the time when teams come together again after the lockdown. We will likely see teams that have created technical and social debt struggle for extended periods of time to get back on track. Getting back on track will require solving technical problems and social issues that have emerged during the work-from-home period. Teams that did well before may leverage the unusual situation and external trigger to grow even more into a mindful and tight-knit group. It will be interesting to study in more detail what can be learned more generally from this extreme situation about software development teams and beyond.

References

Edmondson, A., 1999. Psychological safety and learning behavior in work teams. Administrative Science Quarterly, 44(2), pp.350-383.

Kude, T., Mithas, S., Schmidt, C.T. and Heinzl, A., 2019. How pair programming influences team performance: The role of backup behavior, shared mental models, and task novelty. Information Systems Research, 30(4), pp.1145-1163.

Liu, S., Xin, H., Shen, L., He, J. and Liu, J., 2020. The Influence of Individual and Team Mindfulness on Work Engagement. Frontiers in Psychology, 10, p.2928.

Ramasubbu, N. and Kemerer, C.F., 2016. Technical debt and the reliability of enterprise software systems: A competing risks analysis. Management Science, 62(5), pp.1487-1510.

Tamburri, D.A., Kruchten, P., Lago, P. and Van Vliet, H., 2015. Social debt in software engineering: insights from industry. Journal of Internet Services and Applications, 6(1), p.10.

Yoo, Y., 2010. Computing in everyday life: A call for research on experiential computing. MIS Quarterly, 34 (2), pp.213-231.

Yu, L. and Zellmer-Bruhn, M., 2018. Introducing team mindfulness and considering its safeguard role against conflict transformation and social undermining. Academy of Management Journal, 61(1), pp.324-347.