Working in the COVID-19 pandemic : an observational study

The restrictions of social isolation adopted to contain the spread of the COVID-19 pandemic have led many companies to adopt remote work in a mandatory and unplanned way. This sudden transition has caused profound changes in personal and professional relationships. In this article, we present the results of a qualitative observational study on the adaptations made in the activities of the software development process of two companies. These adaptations were intended to support the transition to teleworking during the pandemic. They were analyzed based on the theoretical framework of Olson and Olson for distributed collaboration. Software developers’ motivations and observed challenges are also presented. Based on these results, the article presents recommendations to facilitate the adaptation to remote work in software development teams.


Introduction
Software development is a social activity with tasks centered on individuals and their relationships, interactions and collaborations. The importance of interaction between software engineers is made explicit in the first value of the agile manifesto: "individuals and interactions more than processes and tools". Meanwhile, the third agile value emphasizes the importance of collaboration between members: "collaboration with the client more than contract negotiation" (AGILE MANIFESTO, 2001). This means that developing software does not only depend on technical aspects, but also on the interactions between the individuals who carry out the activities.
In a work structure where people are allocated in the same physical space, these interactions become natural and find a favorable environment. However, in some situations, it is necessary to interact remotely, adding technological and social aspects within these relationships.
In this context, in 2020, the whole world was surprised by the COVID-19 pandemic. To deal with this new reality, several actions were necessary, especially social distancing, requiring that teams work from home. The restrictions imposed by the pandemic have caused profound changes in labor relations and in the way this work is carried out: many companies were forced to suddenly adopt telework. This sudden and mandatory transition impacted the personal lives of many individuals and their family dynamics (MA-CHADO, et al., 2020). According to RALPH et al. (2020), during the pandemic, people are working remotely, but not in an office or environment prepared for this, but from their beds, kitchen tables, sofas within the family context (children, spouses/ husbands, pets, etc) prone to interruptions, and without support networks such as nursery and schools.
The various aspects that influence remote collaboration have been highlighted by several authors (JOLAK, et al, 2018), (CRAMTON, 2021), OLSON and OLSON (2000, 2008, 2014, BJØRN et al. (2014) within the perspective of CSCW (Computer-Supported Collaboration Work) and Software Engineering. However, there is still a limited number of publications that focus on remote work during crises, such as the COVID-19 pandemic, simply because the world has not been affected by a similar situation since the emergence of the World Wide Web. (RALPH, et al., 2020). The impact of the pandemic required rapid adaptation to a new way of working, using collaborative tools that allow document sharing, synchronous work and videoconferencing. In this context, the scale of adoption and use of such tools during the period of social isolation quickly surpassed what we know about collaborative systems.
Thus, in this work, we describe how the activities of the software development processes of two organizations were adapted to remote work during the COVID-19 pandemic. We present these adaptations, their motivations, the challenges encountered, and recommendations for improvement using as reference the framework for distributed collaboration by OLSON (2000, 2008).
This article is organized as follows. Section 2 details the distributed collaboration framework and is followed by the methodology used in this work. Sections 4 and 5 detail work before and after the pandemic. Section 6 presents the analysis of adaptations according to the dimensions of distributed collaboration. Section 7 presents a discussion of the results while section 8 describes recommendations for organizations that are adapting to teleworking. Finally, section 9 presents conclusions and future work.

The Distributed Collaboration Framework
The distributed collaboration framework of OLSON (2000, 2008) was used as a theoretical framework in this study. It describes five key dimensions associated with telecommuting success: common ground, coupling of work, collaboration readiness, technology readiness, and organizational management. This framework was identified based on several years of research on collaboration across distributed teams. For this reason, it can be used to "assess" a distributed team's readiness to handle the challenges of distributed collaboration. However, it is noteworthy that the concepts of remote work success presented by Olson and Olson did not consider crisis situations.
According to Bjorn et al. (2014), common ground refers to the knowledge that people share with each other, which allows us to understand each other's assumptions; coupling of work refers to the interdependence between the tasks performed by employees; collaboration readiness refers to how much the participants of distributed teams are ready to engage in collaborative activities, despite the distance; technology readiness refers to the difficulties faced in adapting, adopting and using technologies for collaboration; and, finally, organizational management refers to the practices and policies by which management activities contribute, or not, to collaboration at a distance. These five concepts that make up the Olson and Olson framework will be considered in section 6 (results) as an analytical lens in the analysis of the adaptations of distributed collaboration in the context of the COVID-19 pandemic.

Methodology
The methodology used consists of qualitative empirical research, through participatory observation of the teams' work process, described here as Case 1 and Case 2. Participatory observation allows the researcher to observe and understand the events, the situations and the study participants while acting with them (FINO, 2003).
Thus, for Case 1, the first author participated daily in the work routine, acting as Scrum Master (SM), with the responsibility to ensure that the agile process was followed, facilitating meetings, monitoring activities and removing impediments. For Case 2, the second author also played a leadership role with the team, including exercising a management role. She was responsible for fostering adherence to work processes, ensuring that the project's goals were met with stakeholders. In both cases, the members of the observed teams were aware of the study, i.e., the study was discussed in a meeting with all team members. The privacy of the team members, teams and institutions was preserved by omitting their identification.
Data collection was carried out based on participatory observation of the work routine of the two teams, as well as through interactions between the team and with stakeholders. Field notes were prepared between mid-March and De-cember 2020, based on conversation logs from communication tools, activities documented in collaborative project management tools, artifacts stored in the shared repository, feedback from participants in retrospective meetings (SCRUM GUIDE) and at other meetings. During the period of data collection, this documentation, with restricted access, was shared only among the authors for data analysis.
Data were analyzed as follows. Initially, the first and second authors, independently, selected the field notes that were related to the framework of Olson and Olson, respectively for Case 1 and Case 2. Then, together, these authors used a deductive approach to analyze the data obtained in the field notes, according to each of the five dimensions of the distributed collaboration framework under the guidance of the last author. Subsequently, two other authors revised the analysis to avoid possible bias. The analysis aimed to understand whether the adaptations of the software process during the period of social isolation due to the pandemic met the recommendations of the framework by Olson and Olson. This collaborative data analysis process was carried out through online meetings and using shared documents.
In the following section, the contexts, the original software process (both mapped before the onset of the pandemic) and the adapted software processes will be described for each case studied.

Case 1: University technology coordination (UTIC)
UTIC's is responsible for the development of software systems required by one of the pro-rectors of a Brazilian university, in addition to the support of systems already in its portfolio. Specifically, the first author of this article is a UTIC employee, so he had access to software process data before and during the pandemic.
During the period observed, the development team consisted of ten employees: two civil servants and eight scholarship holders in the information technology area. The composition of team members, based on the roles of the Scrum framework (SCHWABER AND SUTHERLAND, 2020), had a Scrum Master (SM), a Product Owner (PO) and the Scrum Team, who are the members responsible for the implementation of product. Members outside the coordination area also interacted with the team, such as specialists from the business areas, called stakeholders.
Data collection ranged from the beginning of the period of social isolation, in mid-March to December 2020. In this interval, the UTIC team executed 5 projects, 4 related to legacy systems, with evolving maintenance demands and 1 new project, which started right after the beginning of the pandemic, having all its steps executed with the team working remotely.

Original software process
UTIC's software development process consists of seven steps. An original version can be found in MONTEIRO and OLIVEIRA (2019), but this article considers the updated version, which includes adjustments in the initial stages, referring to the activities: Build Comprehensive Model, Plan Releases and Build Product Backlog. An overview of this model is presented in Figure 1. a. Build Comprehensive Model: this activity aims to align with stakeholders the ideas regarding the minimum viable product (MVP) to be built and its increments. All team members participate in this stage and tools such as whiteboard, flip-chats and post-it are used.
b. Plan Releases: aims to define the sequence in which the product's functionalities will be delivered. The entire team participates in this activity and the main tool used is a physical board called Canvas MVP.
c. Build Product Backlog: aims to create and develop an effective and collaborative product backlog (SCRUM GUIDE). Everyone participates in this activity and the main tool used is another physical board called Product Backlog Building Canvas, or simply, PBB Canvas. d. Execute Sprint: aims to execute the product's construction sprints. The main tools used are User Stories Card on post-its; Kanban physical board for visual management of work progress; Adobe XD and Bizagi tools for prototyping and modeling; Eclipse IDE and PHPMyAdmin for software development and database management; finally, GitLab for version control and Cypress for automated testing. e. Increment Product Version: aims to integrate the code of the User Stories developed, to make the version available for approval. The person responsible for carrying out this activity is the Scrum Team and the tool used is the GIT-FTP versioning platform.
f. Homologate Product Version: aims to present a new version of the software product to the Product Owner (SCRUM GUIDE), in an approval environment, for evaluation. The entire team participates, and User Stories manual/paper cards are used.
g. Deliver Product Version: This activity makes the new product version available to end users in a production environment. The person responsible for carrying out this activity is the Scrum Team. The used tool is GIT-FTP.
The high-level description of UTIC's software development process allows observing the performance of various coordination and alignment activities in person with the entire team, as well as the use of tools that require the presence of everyone in one same shared physical space. For example, planning releases requires the collaborative construction of an artifact, using a physical board and post-its.

Adapted software process
As an employee of UTIC, the first author of this work was responsible for adapting the software process keeping the agile software development practices already adopted, but through remote work (see Figure 3). In addition, it was also decided to make the workload more flexible, where the team could include alternative shifts to perform their tasks, not needing to follow the established business hours, managing the allocation of work shifts using a shared spreadsheet on Google Drive. The activities of the process and those responsible for their execution remained unchanged: the changes only occurred in the use of collaborative tools to assist in the execution of activities. During the Build Comprehensive Model, Plan Releases, Build Product Backlog and Homologate Product Version activities, the meetings between those responsible for the tasks were held by videoconference through Google Meet. Google Drive was adopted for file sharing throughout the process. For the Build Comprehensive Model, Plan Releases and Build Product Backlog activities, carried out with the presence of stakeholders outside UTIC, the duration of the dynamics also needed to be adapted. Before the pandemic, stakeholders set aside a period, or even an entire day, to carry out these activities. However, the adaptation of the dynamic's realization time was reduced due to the virtual format where, in this context, interactions are more focused, without so many intervals.
In the activities of Build Comprehensive Model and Plan Releases, with the limitation of the use of physical frames, the Web Mural tool was adopted with the Lean Inception template (CAROLI, 2018) for the visual and digital management of these activities, allowing the simultaneous collaboration of members on the virtual board.
To build the Product Backlog, the Web Mural tool was used again with the Product Backlog Canvas template (AGUIAR and CAROLI, 2020), to manage the activities, now in a digital format, offering shared access as well for the stakeholders. In addition, Trello was used to organize the Product Backlog items generated in this activity. This tool was also used during Sprint execution.
For internal communication between the members of the agile team, Discord was used, as it allows the creation of communication channels via text, audio, and videoconferences. At UTIC, channels are organized by project, technical and business support channels offering access and free contribution at any time of the day for all internal UTIC members (SM, PO and Scrum Team). There is also a socialization channel, called #topic-off, used for informal conversations between team members, with links to courses and training, information about the COVID-19 pandemic and general issues. The technical and business support channels, called #help-tecnico and #help-negocio, were used for technical questions and related to the understanding of business rules (User Stories), respectively. All channels were used by the team, with #topic-off being the most frequent, mainly for updating information about the pandemic and vaccination.
The activities linked to the construction of the stories were carried out in pairs, assigned in Trello, according to the availability information in the Google Drive spreadsheet already mentioned. On the other hand, the retrospective meetings were carried out in FunRetro, which allows visual management of the ceremony, recording of participant information and set of the duration of the meeting. Other resources of GitLab were also used, such as the Wiki, for knowledge management: Scrum Team members recorded the standard procedures for carrying out certain activities, allowing collaborators to access this content, if necessary.
In the activities of Incrementing and Delivering the Product Version, communication between the team was carried out via Discord and Trello to indicate the User Stories that would compose the version. Relevant artifacts were shared via Google Drive, so that everyone involved could access and contribute. Finally, in the activity of Approve Product Version, the Trello tool was used to manage User Stories changes, defects, and improvements.

Case 2: Internal group of a technology company
The researched environment consists of a mixed capital company, in the information technology area. This Brazilian company has more than three thousand employees, is headquartered in Brasília and has branches in several cities across the country, including Belém, where the systems development center reported in this study is located. This center is organized into two groups, one of which is dedicated to the development and support of internal systems for use by the company itself.
In the period covered by this research (February to December 2020), the group of internal systems participated in 6 software projects (having completed 3 in the period) and developed activities to support 11 systems already in production. However, to carry out this study, the process analysis was carried out only on the software projects. The project had 10 (ten) team members, 2 (two) requirements analysts, 6 (six) developers and 2 (two) quality analysts. In addition to the technical team, the project was also monitored by the management of the internal systems group, which played the role of "project manager". The group worked using a traditional software development methodology, however, it used a few good practices of agile models, such as the division of work into sprints, daily meetings and the use of backlog.

Original software process
In Case 2, an incremental iterative development process was adopted, made official through internal company norms. In general, the process and tools used can be defined as shown in Figure 2. a. Backlog Definition: aims to identify the needs of stakeholders and prioritize them to create a work backlog. The stakeholders and the requirements list analyst and the team's senior developer participate in this stage. To achieve this goal, face-to-face meetings can be held in travel opportunities between participants from different headquarters or remote interactions via Microsoft Teams (MS Teams) through calls via the VOIP channel that interconnects the organization's units or video conference.
b. Backlog Refinement: refine the understanding of prioritized backlog items in order to support the development team for the next phases. At this stage, considering that the development team is in another city, the tool used for interactions with stakeholders is MS Teams. Among the members of the development team, face-to-face meetings are held using tools such as a notebook, projector, and whiteboard, as well as documentation in text files shared in the project repository.
c. Sprints Execution: aims to build the software product based on the backlog refined and prioritized in the previous steps. It consists of planning the work to be performed, carrying out the activities of building the software itself, periodically monitoring these activities and providing a final balance on the results obtained. The work is developed in 2-or 3-week Sprints. Follow-up activities are carried out in faceto-face meetings using a whiteboard, post-its and applications from the Microsoft Office package. With the team working face-to-face, any difficulty, impediment or doubt is dealt with through informal personal contacts or on-demand requested meetings to go deeper into some important topic for the execution of the tasks. The project manager records in Power Point, throughout the Sprint, important notes to be addressed/reported in the check point.
d. Check Point: report weekly to stakeholders the progress of planned activities, possible risks and impediments. Representatives from the client area, managers of the development center, as well as the project requirement analyst, participate in this event. The tool used, given the physical distance between the parties, is the MS Teams audio conference, with screen sharing for the presentation in Power Point. e. Team Communication and Integration: eventually, when necessary to make general communications or alignments for the entire group of internal systems, regardless of the project, a general meeting can be called verbally in the workroom or via the organizational calendar. The meeting is held in person in the meeting room, and Power Point, whiteboard and projector can be used to support the discussion of the topics on the agenda.

Adapted software process
As manager of the internal systems group, the second author was responsible for implementing, with the team, the necessary adjustments to carry out the work in the new context of remote relationship (Figure 4). Considering that in Case 2 interactions were already taking place through remote collaboration tools, due to the development team and the stakeholders located in different cities, the adaptations were especially concentrated on the interactions carried out between members of the development team. Regarding working hours, in case 2, it was necessary to maintain business hours, without any changes. The activities of the process and those responsible for its execution also remained unchanged. The changes occurred basically in the intensified use of already established tools (Office 365 and Azure DevOps -both from Microsoft), abandoning the tools linked to the office infrastructure (whiteboard, projector, video conferencing and VOIP) and the informal adoption of Discord.
For the Backlog Definition and Backlog Refinement activities, it was no longer possible to use the Voice over IP (VOIP) channel provided by the organization, since the work was now carried out in a home office format. It was also no longer possible to hold face-to-face meetings, thus eliminating the use of physical tools such as a whiteboard and a projector. However, the use of the MS Teams was intensified as the main (and now only) communication channel between those involved. These interactions took place through the features of chat voice meetings, either through direct dialogues or in groups, created without systematization, but spontaneously by the team, according to the need for communication. During this period, the video conference func-tionality was not used for this activity. The creation and refinement of the projects' backlog continued to be carried out through the tools of the Office 365 suite or through the adoption of Azure Boards in some projects.
For sprints execution, face-to-face meetings and the use of the whiteboard were replaced by the intense use of MS Teams, in the format of audio meetings and chats. In the first week of remote work, specific groups were created for each work front, with the technical team involved and the group manager, to maintain an "open line" of communication on specific aspects the day-to-day of that project or system in support. These groups were marked with the prefix "@dev-Team" and aimed to mimic -within the limits of a collaborative tool -the freedom of face-to-face interaction that the team had by working physically close in the pre-pandemic period. Another motivation was the centralization and creation of a history of the subjects dealt with once most of the team members participated in more than one "@devTeam" room. This feature was used in the modalities of chat (with intense use of gifs, emojis and reactions), file sharing, collaboration on shared files and audio calls. These interactions took place -in writing or audio meetings -spontaneously for day-to-day matters, such as notices of temporary absences and occasional personal matters.
Interactions regarding the accomplishment of project tasks also took place freely, as required by the team or management. Occasionally, a meeting that required the attention of the entire group or the formal discussion of a more complex issue was scheduled on the corporate calendar so that everyone could attend it. The parallel use of an unofficial channel in the Discord tool for audio communication according to the need for interaction for asking technical questions and occasional activities that needed to be carried out by multiple people, such as meeting the demands of systems already in production that required greater attention and joint action by the requirements analyst and the developer.
For the planning, monitoring, and closing of the sprints, a systematic control of activities was established through an adaptation of the Power Point presentation previously used for check points with the client. In this presentation, the progress of activities was updated throughout the week in meetings between the project team and the group management. In these opportunities, impediments, risks, impacts, the need for re-planning and completion of stages were pointed out. Some projects also started using Azure Boards for planning and monitoring sprint tasks, as well as for conducting retrospectives.
The activity of Performing Check Points with representatives of the applicant area, senior management, and key user, had no great impact on the format already used before the pandemic, since the internal systems group had historically conducted this activity in a remote way. MS Teams and Office 365 tools were used to carry out weekly control points, since all its stakeholders are geographically distributed in other branches. Using the channel on MS Teams for executive monitoring, also involving the company's project office sector, was regarded as "official" in the organization. Thus, for each project, a group was created in MS Teams, identified with the # symbol and the project code in the company's master plan. This group was basically used to communicate risks or impacts on project milestones, impediments that needed management support, and disclosure of weekly check point records. It has established itself over time as the official channel for management formalization on the progress of the studied team's projects.
To promote the integration of the whole group of internal systems, a virtual room was created in MS Teams, involving members from all work fronts to provide a space for sharing news and promote team integration. The practical objective of carrying out comprehensive communications and alignments to the entire group also extended to the promotion of integration between the team, which previously occurred naturally in the face-to-face environment. After a few months of remote work, the group's management took the initiative to hold not only audios, but video meetings, so that the team could see each other, create an atmosphere of relaxation and exchanges about aspects of private life, workspace, pets, children, etc.

Reflections about the cases presented
The sudden migration to remote work demanded adaptations in the execution of the existing software development processes in both organizations observed. Despite differences between the work methodologies adopted and the tools used, it is possible to draw parallels between the two experiences.
In UTIC's experience, agile practices were already more robustly implemented in the day-to-day work before the start of the pandemic. Thus, the adaptations carried out aimed to use a variety of tools to maintain these practices remotely.
In the internal systems group, some activities in the development process were already carried out in a distributed way even before the compulsory start of remote work. These interactions took place mainly using tools for remote communication (MS Teams, video conference room and telephone calls via VOIP) between members of the Belém team and stakeholders from other branches, such as Rio de Janeiro, São Paulo, Piraí and Brasília. In addition to the communication tools, the software development suite and auxiliary tools were already well established in the team, so that no great impact of process modification or adoption of new tools by the team was noticed to carry out their activities in a completely remote way.

Results
To classify the adaptations identified in both cases, the five concepts for distributed collaboration were used according to the framework of Olson and Olson, detailed in section 2.
Each of these five concepts is used as an "analytical lens" to explain how the adaptations made can aid the remote work process during the pandemic. In addition, distributed collaboration challenges were also noted and reported.

Common ground
a. Analytical Framework: According to the concept of common ground presented by Olson and Olson (2000) and considering the perspective of (BJORN et al, 2014), it can be said that the teams of both cases studied already had shared a common ground about business aspects, working methods and mutual knowledge, as the teams remained the same before and after the start of remote work.
b. Adaptations Case 1: Team members used shared resources (documents, Trello boards, etc) to document decisions and plansand synchronous and asynchronous conversations to discuss ideas, answer questions and resolve disagreements. These activities together allowed for the construction and maintenance of a common ground. Due to the pandemic scenario, these tools were configured as the only possible means of communication, and no other type of interaction was observed in the period to promote common ground between the team, thus reinforcing the importance of this aspect in the context studied. The main communication tools included: Google Meeting for remote audio and video conference meetings with stakeholders and Discord for meetings in text, audio, and video channels between Scrum Team members. Tools were also used for visual management of agile dynamics with resources to facilitate collaboration between participants, with emphasis on the Web Mural for remote collaborative dynamics of Lean Inception and Product Backlog Building, Trello for managing tasks, and FunRetro for the retrospective dynamics at the end of each Sprint.
Case 2: There was little change in the set of tools and in the process developed by the team, sharing the common ground that the team already had since before the beginning of the remote work. The previous understanding of the challenges during long-distance collaborations, and which were restricted to teams that worked in different cities, expanded to the relationships among all team members, who started to interact only through collaborative tools. However, the intimacy already developed between the team members, the team's familiarity with the tools used, the preparation of MS Teams with the creation of specific 'rooms' for each project, the interaction with stakeholders and the holding of meetings with the camera open for periodic team integration were positive factors so that common ground continued to occur. There were various features of MS Teams that promoted awareness among team members (DOURISH and BEL-LOTTI, 1992), which facilitates common ground throughout interactions: indication of user status (busy, on the phone, absent, disconnected, online), use of gifs, images and reactions to express feelings and understanding of a message, visual information that a person is typing or has read the message sent, among others.
c. Challenges Case 1: Communication between the agile team was sometimes done through voice channels (Discord), or through videoconference tools, but with the cameras turned off. In this context, greater challenges were observed for communication, which demanded greater effort to establish common ground, when compared to opportunities for face-to-face interaction. Other tools did not show relevant challenges in the process of promoting common ground, as they offered the possibility of exchanging information with resources such as images, text and links.
Case 2: The challenge of losing the informal relationship that the team had in the co-located work was mitigated by two initiatives: holding integration meetings with open camera and creating specific rooms for each project and the whole group. In general, the challenges naturally presented by the work process changes were mitigated by the team within the tools provided by the company itself.

Coupling of work
a. Analytical Framework: According to (BJØRN et al., 2014), tightly coupled work causes remote participants to interact more frequently. This is the opposite of what was initially proposed by Olson and Olson (2000): the success of distributed work depends on the loose coupling of activities. This new perspective points out that the nature of the task engages teams to invest time in interactions even while remote.
b. Adaptations Case 1: Work shifts became more flexible, allowing for freer interactions, according to the availability documented in the shared timetable. Thus, there were no changes in coupling for performing tasks in pairs, but a facilitation for interaction between members of different shifts.
Case 2: There were no sudden changes in the coupling of the work performed, as the team did not act in pairs on a regular basis. For activities carried out in a tightly coupled manner, the use of audio meetings through MS Teams and the informal adoption of Discord can be mentioned. The sharing of documents through Office 365, the use of Azure Boards also contributed to the realization of strongly coupled activities such as coordinated alteration of files and the realization of dynamics in virtual collaborative frames.
c. Challenges Case 1: Tasks that demanded more repetitive effort, when performed in pairs, generated demotivation for the more experienced members of the Scrum Team, such as: generating reports, creating scripts for database-related tasks and changing server configuration. In these cases, maintaining the pairing proved to be a challenge, however, it remained valid, as it allowed the dissemination of knowledge with inexperienced members.
Case 2: In the situations where the tasks required high coupling, some people on the team did not adapt to the collaboration options offered by the corporate tool (MS Teams), leading to the informal adoption of Discord, which offers an independent voice channel, not being "stuck" to a call as in MS Teams.

Collaboration readiness
a. Analytical Framework: According to BJØRN et al. (2014), collaboration readiness is about how motivated participants are for collaborative activities. Thus, informal communication helps to promote collaboration and coordination of activities. It is noteworthy that in the scenarios analyzed in this study, remote interaction was in fact the only available alternative. Another important aspect pointed out by Olson and Olson (2000) is that the simple introduction of collaborative tools in organizations that do not have this culture may not result in a readiness for collaboration.
b. Adaptations Case 1: Creation, of specific channels for collaboration between the team, on Discord, in addition to the use of the worksheet in pairs, covering all people, regardless of their work shifts, served to foster a friendly environment to collaboration. The help and socialization channels in Discord helped the team members to collaborate more with each other, either with quick feedback or offering the possibility to share knowledge and discuss about topics not related to the job to be done. This helped members get to know each other better and helped to minimize the sense of social isolation caused by remote work during the pandemic.
Case 2: The creation of specific rooms in MS Teams for each project and a single room for the entire team favored collaboration by promoting commitment, trust and transparency among participants. The homogeneity of the organizational culture, technologies and work practices favored the readiness for collaboration among the studied team.
c. Challenges Case 1: The intensive use of communication tools generated concern in the team regarding requests outside working hours and the large number of messages. Finding a balance between the demands of professional and personal life is still a challenge in the context of telecommuting, especially during the pandemic.
Case 2: The number of meetings throughout the week was a challenge to the team, with some projects having adapted not happen daily, but only twice a week. Other projects invested in holding more objective daily meetings with special attention to the content discussed in the meeting and its duration. Regarding interactions with stakeholders, who already had a relationship with the development team based on collaborative tools, no challenges or resistance to collaboration were identified after starting the remote work.

Technology readiness
a. Analytical Framework: OLSON and OLSON (2000) say that the misalignment in the adoption and support of tools is one of the biggest inhibitors of the successful adoption of collaborative technologies. The concept presented by (BJORN et al, 2014) -a modern approach -associates the challenge of technology readiness with the concepts of stability, accessibility, and availability of technologies to support collaboration.
b. Adaptations Case 1: Considering the introduction of new collaborative tools in the routine of UTIC and stakeholders, it became necessary to carry out some training for remote work and create help and support channels, in order to promote the readiness to access and use collaborative technologies. Thus, training guided stakeholders about remote work, explaining the dynamics to be adopted in each software development process activity, as well as offering instructions for the necessary configurations of the collaborative tools.
Case 2: Most tools used in the adaptations for remote work were already known by the team, they did not present instabilities, unavailability or access difficulties, through all process activities without imposing specific challenges to this dimension of the framework.
c. Challenges Case 1: Problems related to the stability and quality of the internet connection were identified, impacting the progress of collaborative activities. Some team members also had difficulties because they did not have adequate equipment to carry out remote work from home. In some cases, it was necessary to share the computer with other family members, in others, the equipment had low capacity for ideal use and performance of the activities.
Case 2: No challenges were identified during the adoption of new tools, however, instabilities were reported in the VPN connection established between the personal computer of some team members and the corporate machine remotely accessed at the unit's headquarters.

Organizational management
a. Analytical Framework: Organizational aspects are recognized as important to create conditions that enable collaboration (BJØRN et al. 2014).
b. Adaptations Case 1: UTIC was free to adapt its work process. The agile practices used before the pandemic were maintained, however, adapted to the context of remote work. As discussed earlier, adaptation involved the adoption of collaborative tools supported daily communication between team members. The flexibility in the workload also allowed the team to choose the most appropriate time to perform their tasks and organize their personal routine, in addition to allowing people who worked in different periods in face-toface work, to have the opportunity of working together in pairs.
Case 2: The role of organizational management could be perceived through the development center team manager's proactive performance, which built with the team mechanisms to promote the engagement and support necessary to carry out activities remotely. Among these mechanisms, it is possible to mention: the creation and formalization of the team's communication channels, the adaptation of periodic ceremonies to align activities, the promotion of informal meetings between the team and the encouragement of the adoption of support tools for remote work already available in the organization.
c. Challenges Case 1: Senior management continued to send demands with the deadlines and targets stipulated in the strategic planning carried out before the pandemic. Thus, these external pressures caused tension in the team. It was also noticed that, probably because the switch to remote work was made suddenly, the organization did not provide standardized guidance to the team, which required some adaptation time, es-pecially for less experienced employees. As mentioned earlier, regarding the difficulties related to physical and logical infrastructure, there was no support from senior management to mitigate these problems, thus each member had to identify mechanisms to solve them.
Case 2: The organization did not offer equipment (hardware), and the team had to use their own computers and notebooks. Peripherals were provided in a few cases, only if requested by the team member. No financial support was offered for adapting the physical space, creating adequate infrastructure for working from home (internet, tables, chairs, etc.) or covering extra costs of electricity or internet.

Discussion
From the moment the covid-19 pandemic transformed labor relations, several researchers started working to understand and document these changes. Part of this research has focused on software development and collaboration aspects. Indeed, we identified 8 relevant papers in software engineering and/or CSCW journals or conferences. Most of these works performed an analysis focused on the productivity of software developers (RALPH et al., 2020;RUSSO et al., 2021;MILLER et al., 2021;OLIVEIRA et al., 2020). Other characteristics explored were well-being (RALPH et al., 2020;RUSSO et al., 2021;CALDEIRA et al., 2021) and issues related to interruptions when sharing the home space with other family members, especially with small children (CALDEIRA et al., 2021;MACHADO et al., 2021). Another aspect studied is the importance of balance between personal and professional life (WHILLANS et al., 2021;MILLER et al., 2021;CALDEIRA et al., 2021;YANG et al., 2021). Only 2 of these papers also adopted the distributed collaboration framework of OLSON (2000, 2008) for assessing the period of remote work during the COVID-19 pandemic.
Differently from previous work, in this paper we explore the software development process adaptations carried out in two real organizations to contemplate the reality of remote work motivated by the COVID-19 pandemic. In Case 1, UTIC, it was observed that the activities of the software process and those responsible for their execution remained unchanged. However, the way these activities were performed had to change: the main changes that took place were the rapid adoption of collaborative tools for carrying out tasks remotely. In particular, the activity "Run Sprint" required several new communication and coordination channels.
In the internal systems group, Case 2, as some activities of the software process were already taking place remotely before the pandemic, the main adaptations refer to the use of communication channels between the members of the development team, specifically intensifying and systematizing the use of the MS Teams tool. Within the context of communication channels, it is worth emphasizing the informal adoption of Discord to carry out strongly coupled tasks. Another adaptation was the use of tools from the suites that were already organizationally available, but which had not yet been adopted by the team, such as the virtual board to control development activities.
As detailed in the previous section, the adaptations in both cases can be explained through the concepts of the Olson and Olson's (2000) distributed collaboration framework, so that the results were structured according to it.
With regard to common ground, in both cases the teams were already working together and co-located before the pandemic, sharing personal and professional knowledge before the need to adapt to a totally remote work model. To UTIC, the distributed work experience was completely new, however, to the internal systems group, the adaptations were more specific, as they already had institutionalized collaborative tools through which they contacted co-workers in other company units, in different cities.
Regarding the collaborative tools adopted, it's characteristic of allowing quick feedbacks and information sharing was important to support remote work. Olson and Olson (2000) have already addressed the importance of these tools, also reporting the technological limitations from that time, such as the low quality of audio and video that limited the understanding of what is said and the identification of who was speaking. However, such challenges are currently less present (BJØRN et al., 2014) and have not been reported in the cases studied. Challenges related to the richness of communication are directly connected with the success of common ground and cases of videoconference communications are more successful than those that only used audio (Watson-Manheim and Bélanger, 2002).
In Case 2, open camera meetings were included in order to encourage integration among participants, thus fostering opportunities to develop common ground. On the other hand, in Case 1, the conditions of access to these technologies needed more attention, as limitations related to infrastructure, equipment capacity of the team members and the instability of their connections made meetings in videoconference difficult. Thus, the lack of adequate infrastructure directly harmed the common understanding in Case 1.
Regarding the coupling of work, in Case 1 a dichotomy was observed in the results between developers with different levels of experience. For those more experienced, performing in a group simple or repetitive tasks can be exhausting due to the additional work required to perform strongly coupled activities; this is similar to the report by Bjørn et al. (2014). For less experienced collaborators, this practice was important to reduce the learning curve and facilitate the sharing of knowledge (OLSON and OLSON, 2000). A reduction in the coupling of tasks was not observed, but as expected, these tasks were transferred to digital environment through the adoption of collaborative tools. As for Case 2, most tasks were loosely coupled, with the collective effort concentrated in planning moments and in daily meetings, where possible impacts between everyone's tasks were discussed. Thus, for the eventual performance of strongly coupled tasks, the team's spontaneous adaptation was perceived, adopting the Discord tool as an alternative for prolonged contact.
Regarding collaboration readiness, the communication channels created in the collaborative tools were positively perceived in both researched cases, promoting synchronous and asynchronous formats to establish communication between teams. Opportunities and socialization channels were also created to provide an environment for exchanging ideas and informal conversations among employees. Similarly, Ford et al. (2020) reported in their research on software development during the pandemic that spontaneous and informal interactions -such as the virtual coffee time -were highly appreciated. The "virtual coffee" room was also reported by Oliveira Jr et al. (2020) as a way of socialization or support in software development solutions.
Regarding the technology readiness, in Case 1, meetings were held to prepare for remote work and support channels were made available to employees. The importance of preparing the environment for remote work was also reported in the works by Caldeira et al. (2020), Bao et al. (2020) and Ford et al. (2020). As for Case 2, the employees were already familiarized to work with the MS Teams to communicate with stakeholders from other cities, so they did not need specific training.
Finally, it can be observed that most of the recommendations for improvements reported in the literature regarding remote work during the COVID-19 pandemic (FORD et al., 2020;RALPH et al., 2020;MACHADO et al., 2020) are centered on the organizational management dimension. For example, financial incentives to purchase internet packages, workstations, and peripherals suitable for remote work, as well as ergonomic furniture were not present in both cases surveyed, as they did not have the proper support from senior management to mitigate these physical and logical infrastructure problems. These incentives importance has been highlighted in related articles (FORD et al., 2020;RALPH et al., 2020). These initiatives impact positively in other dimensions of the distributed collaboration framework.
In the next section, we propose recommendations for organizations and individuals working remotely in crisis.

Recommendations
This section aims to offer practical recommendations based on the results obtained through the case studies analyzed. We organize them according to the OLSON and OL- SON's (2000SON's ( , 2008 distributed collaboration framework. These recommendations are presented in Table 1. To facilitate common understanding, it is recommended that at least some meetings between team members are held by videoconference, with the camera on, as video meetings allow those involved to use gestures and facial expressions as a way to obtain feedback and awareness of the state of your co-workers (if they are surprised, sad, focused, stressed, happy, etc.).
From the point of view of work coupling, it is recommended to enable the decoupling of work for specific tasks, especially those repetitive and with less intellectual effort. However, these activities should be documented to serve as a guide for other team members. This is in line with the recommendation of the GitLab company, which prepared a "Remote Work Manual" (FORD et al., 2020) where it suggests maintaining the use of formal repositories to centralize tips and relevant information about the steps of execution of the tasks. With this practice, more experienced members can focus on more complex tasks that require more interaction with other team members. For those tasks that really need joint work, it is suggested to re-evaluate the available tools so that they can make it easier for the team to carry out the work.
In terms of collaboration readiness, this is not just about improving tools and processes, but there is also important organization support regarding maintaining a balance between work and personal life. Specifically, focus on workload flexibility and the use of collaborative tools outside office hours, to avoid overload and to encourage a healthy lifestyle.
Regarding the technology readiness, it is suggested that senior management recognize the importance of financial support to enable a good work environment, purchasing internet packages and provide adequate access to corporate tools, suitable workstations and peripherals, as well as ergonomic infrastructure. Preparatory training with stakeholders concerning the use of collaborative tools is also recommended, as well as providing help and support channels.
Finally, from the point of view of organizational management, it is suggested to make transparent to senior management the complexity existing in comparing productivity with the pre-pandemic period, avoiding excessive workload expectations. Following the example of the company GitLab, which prepared a "Remote Work Manual" (FORD et al., 2020), it is recommended the preparation and dissemination -among all employees -of a organization good practice's guide about remote work from home. This document should contain organizational guidelines, as well as tips on the proper use of collaborative tools. In addition, it is important that the organization can provide the necessary infrastructure to carry out the work from home, either by providing equipment or offering financial assistance for this purpose. In this perspective, suitable workstations and peripherals are contemplated, as well as ergonomic tables and chairs.

Dimensions
Recommendations Common Ground -Meet by videoconference, with camera turned on; -Promote team integration (virtual when necessary) events to foster inter-personal relationships. Coupling of Work -Enable decoupling of work for specific tasks that are repetitive and require less intellectual effort; -Provide the most suitable tools for carrying out strongly coupled work; -Adopt knowledge management tools. Collaboration Readiness -Guide employees on balance between professional and personal lives; -Offer a flexible workload; -Create virtual spaces suitable for each objective (collective, specific for a project or team, etc). Technology Readiness -Present to senior management the importance of initiatives to provide access to the necessary technologies for remote collaboration; -Conduct preparatory training with stakeholders for the use of collaborative tools; -Provide help and support channels for the good use of tools. Organizational Management -Disseminate guidance for remote work among employees, containing organizational guidelines and tips for the proper use of collaborative tools and steps in the process; -Present to management the complexity of maintaining productivity in a crisis and that excessive pressure can generate an unpleasant work environment for employees; -Support adaptations of the physical home work environment to ensure an ergonomic and safe workspace for employees.

Conclusion
This paper analyzed two real cases of software development teams whose process were adapted to remote work from home, during the period of social isolation due to the COVID-19 pandemic. These adaptations were critically analyzed according to the five concepts for distributed collaboration proposed in Olson and Olson's (2000) framework. Challenges encountered during this transition are also presented. The remote work context analyzed in the literature is prior to the context to which technology professionals were submitted in the last year, due to social isolation. In this sense, aspects related to adaptations to the new remote work context still need to be addressed, especially in crisis situations. The opportunity to analyze two real scenarios, presented through the studies of Case 1 and Case 2 where it was possible to monitor the daily lives of people involved in the projects, stands out as one of the main contributions of this work. Furthermore, using the Olson's framework as an analytical lens through its 5 dimensions/concepts for success in remote collaboration expands the CSCW community's ability to understand the impacts of the changes experienced during a crisis. Finally, the article presented recommendations for adapting to remote work. This paper has limitations both in scope (two teams) and in methodology, since the active participation of two of the authors working in the observed teams may have introduced biases in the observed actions of the team members. In general, these actions were observed through digital records of the activities performed. Finally, it should be mentioned that the Case 1 organization made changes to its software process in January 2020 and the remote work started in March 2020, while the Case 2 team ran a traditional development process, using some agile practices. Thus, it was not possible to assess similarities or relationships of development processes that can be compared in the two experiences.
As future research, several variations of this scenario can be studied in order to validate the results of this paper. For example, after the implementation of the identified improvements, a new survey can be conducted to verify if the challenges identified initially were addressed or if new ones emerged. Finally, it would be interesting to consider how effective the adaptations in the software process were from the standpoint of productivity for the context and team observed.