DISTRIBUTED PROJECT TEAMS: OBSERVATIONS FROM THE LEADER’S SEAT

Introduction

March 2020, the world stopped being normal. What we thought was just two weeks working from home became a much longer arrangement. Beginning in January 2020, we started a new internal research and development project. Our goal was to build the minimal viable product (MVP) as a re-architecting effort of the core product in our division. This effort mapped to the strategic plan and roadmap of our division. In March, a bit over two months into our efforts, everyone was sent home. With the distractions of our home, our family, and the negative news in general, questions regarding the team’s productivity flew to the forefront of our minds.

One team member, engaged earlier in 2019, postponed his wedding. The couple rearranged their plan to marry in a small, quiet ceremony on Pi Day, March 14. Their honeymoon was postponed, rescheduled, canceled, rescheduled again, and canceled again. Their honeymoon is now scheduled for later in 2021, and we are all hopeful they get to take that trip. The team watched the couple navigate through turbulent pandemic times, suffered with them, supported them, and ultimately bonded through the shared experience. Another team member adopted a puppy right as the shutdown began, an adorable black labradoodle. As the team locked down, we got to see the puppy grow via video meetings, bark to go out just as someone was about to present, or bark at someone walking by the house. With all of us in similar situations, we laughed, were embarrassed together, and bonded through the shared experience.

As the product owner on this agile software development team of about nine, the following observations are from the leader’s seat. This paper, a case study for the “New Normal,” is based on a building theory approach to research. With over 25 years of experience in software development and software project management, this case study combines development experience, knowledge from academic research into Globally Distributed Teams, and identified key factors from literature. The research data and theories therein are viewed through the lens of the internal software development program to produce the shaping hypotheses (Eisenhardt, 1989). There is a wide variation in factors found in the literature for a given team or distributed team. However, literature research does consistently consolidate to a set of team practices. The consolidated team practice factors of Process, People, Organization, Technical/Project, and Leadership characterize a team’s contribution to the overall team performance, as shown in Exhibit 1 (Park, 2021).

Process Observations

The Process factor for team practices includes methodology and structure around the agile framework used to develop software. This includes meetings and activities such as the daily standup, user story management, code reviews, closing user stories, and demo at the end of iteration. As an extension of the Agile Scrum process, in several books Gene Kim and others propose an automated test and delivery solution that includes both software development and operations teams called DevOps. DevOps applies lean principles to the development process and includes the operational environment consideration throughout that process (Kim, Humble, Debois, & Willis, 2016). DevOps is still being adopted throughout the industry and shows tremendous value for delivering improved quality in shorter periods of time. DevOps, as defined by Gene Kim, comes directly from the concepts explained by Dr. Eliyahu Goldratt’s Theory of Constraints. From the onset of development for the MVP, the team applied DevOps principles for the project.

Task Conflict is productive and necessary as it is the debate regarding how tasks or features will be implemented. Affective Conflict refers to emotional disagreements between people that are often of a personal nature. Process Conflict describes the differences in how work is performed within the given process (Hinds & Bailey, 2003). Would these forms of conflict be visible during transition from a local scrum team to a remote team?

Naturally occurring task conflict was observed as significantly lessened. When co-located, two team members often debate topics and other team members join in the conversation. It was noted that the team, as a whole, did not discuss or debate many topics when remote. This was, in part, due to the nature of the work from home (WFH) situation and immature tools for group communication. During this period, only Skype was available for collaboration as MS Teams was not, as yet, deployed into the organization. Unlike MS Teams or Slack, which provide perpetual channels for easier collaborative team communication, Skype only provides temporary peer communication. Adding additional users to Skype conversations requires specific user action, and if other parties join late, they are hindered by not seeing the historical context of the conversation. What was noticed is that when two team members worked on similar tasks, they reported that their Skype chat was continuously in use. This is potentially an increase in task conflict communication over standard remote collaboration.

Prior to the team going remote, they had formed trusting relationships, with many of them becoming social friends. Moving to remote work created distance between them but did not seem to diminish the trust built up when co-located. For this reason, minimal affective conflict was observed or reported.

Efficiency and Flow define the ability to complete work with minimal delays (Forsgren et al., 2021). The daily standup and end of iteration demos did not meet this efficiency and flow as the team first went remote—the abrupt change through much of the standard process into chaos. However, over time the team figured out how to communicate via Skype and Zoom with more fluidity. A process was also adapted to improve remote demos. The demos became more scripted. The team created PowerPoint slides that showed what the demo would do and what the screen would look like to the user. This required a slide or two per demo, but the slides were kept extremely simple with large text. The same large text was maintained for the actual demos whenever possible. Handoff between developers also became more scripted. This extra effort was minimized to an hour or two per iteration, but reduced or eliminated the process conflict (Hinds & Bailey, 2003) thus producing smoother standups and excellent demos.

Individual activities such as code writing, code reviews, and pull requests were not noticeably impacted by the WFH remoteness. The agile scrum development process during an iteration consisted of a user story owner who would collaborate with at least one other team member before writing code for the user story. In these design phases of stories, the team used Skype for video chats, instant messaging, and screen sharing to work out the details. This collaboration via these Rich Media connections seemed highly effective, as predicted by Daft and Lengel (Daft & Lengel, 1986).

People Observations

People variables include traits found from research in emotional intelligence components such as openness, agreeableness, emotional stability, conscientiousness, and extraversion (Driskell, Salas, Goodwin, & O’Shea, 2006). These traits contribute to creating trust and psychological safety in a team. Social and cultural factors (language, customs, idioms, religion, etc.) impact how we react and interact with others inside and outside our group (Hofstede & Hofstede, 2005). Knowledge and understanding of these factors are critical in building the bonds between teams in different locations. "Cultural differences often exacerbate communication problems, and because software development requires rich communication, the lack of this can lead to misalignment and rework" (Holmström, Fitzgerald, Ågerfalk, & Conchúir, 2006). With an already formed team, what would happen as the team members move to WFH? Would the shared mental model remain or would trust atrophy?

The team was co-located for approximately two months when the team members began WFH. Most team members had excellent working relationships with each other. While the team operated as a cohesive group toward the goal, their individual skillsets were divergent. This allowed each member to be a point of reference on a topic or skillset. Team members would share their knowledge as a basis to debate the best approach and solution with each other on technical matters. As observed, this was respectfully approached. As defined by Amy Edmondson, Team Psychological Safety goes beyond interpersonal trust and mutual respect to where team members are comfortable being themselves (Edmondson, 1999). Based on these observations, the definition of team psychological safety was met prior to being sequestered into remote situations.

The order to move to WFH was abrupt and occurred with very little preparation. Sufficient prior planning would have made the transition smoother. Following the team’s completed transition to WFH, some observations were immediately apparent. One observation was that each person seemed to have a work persona and a home persona. Some people were not comfortable comingling their work and home environments, potentially because their work and home personas differ. However, other people seemed to flow easily between their work and home personas. Observations confirmed this in several ways with the development team. Some team members eagerly shared a video tour of their home, while others did not even want to turn on their camera.

Process conflict was immediately noticeable as it escalated rapidly due to the uncontrolled and abrupt change in work location and structure. The team lost its sense of safety. As a leader, steps were immediately taken to rekindle the team's psychological safety. One-on-one coaching was provided to guide team members to dress for work, hold work hours, use their cameras, and create a work-like environment in a home setting. The team was encouraged to include their pets as extended teammates by sharing pictures, acknowledging their presence, and including them in meetings. These steps were used to break down barriers and old work beliefs so the team’s bond of trust would not be hindered in the new environmental configuration.

During the pandemic, a new software developer was added to the agile scrum team. Specific steps were taken to integrate her into the team’s shared mental model. These included one-on-one meetings with team members, coaching similar to what was done with the remainder of the team at an earlier time, and inclusion of her pets into the team. We paired the new person with others on tasks until she was fully integrated, understood the vision, and was comfortable taking on her own tasks. The team quickly incorporated her and soon it was unnoticeable that she was our newest arrival.

Organization Observations

The Organization factor includes variables such as management support, infrastructure, corporate culture, and policies, as well as alignment of the project to the organization’s mission, vision, and processes. Research reveals additional variables of identifying appropriate team members, the ubiquity of common tools throughout the team, effective knowledge sharing from the organization, and team autonomy (Guzmán, Ramos, Seco, & Esteban, 2011). In many respects, the organization's goal during the main brunt of the pandemic was maintaining a sense of normalcy, as much as possible.

The federal government designated our division as essential, so staying open and working was a priority. It was not immediately clear who should continue working on campus and who should transition to working at home. Also not clear was how to work at home. Organizational policies such as taking equipment home had to change. Instructions and guidance regarding how to work from home also had to be created and disseminated. Transition to remote work was hampered by the sudden need to work from home. The organization, as well as each individual, was unprepared for the situation. As organizational decisions were made and WFH policies created, many work items and cultures eventually returned to a regular cadence in the “New Normal.” During this period of great fluctuation, teams did the best they could. Teams with heavier equipment needs, labs, and no external connectivity had performance impacts until they could resolve the issues. Many of these teams kept coming into the facility but in shifts to overcome the issue. The more software centric and externally connected teams were impacted less, and effectiveness came back up more quickly. From an organizational perspective for these teams, policies for taking home equipment (monitors, keyboard, mouse) helped somewhat with these teams being more productive.

Projects deemed essential to execute on-site were shifted to a four-day workweek to accomplish additional cleaning. Projects deemed non-essential to be executed on-site were moved to remote distributed constructs. Policies allowing people to take home monitors, keyboards, mice, and other essential equipment were adapted for a remote workforce structure. Internal research and development (IRAD) project teams, such as ours, were directed to WFH.

Virtual Private Network (VPN) issues were the first noticeable sign that a large portion of the organization was WFH. Slow connections and getting kicked off the network were symptomatic signs of the problem. The organization quickly upgraded the connections and physical resources needed to support the remote work. Internal resources that were previously not available via VPN were made available. This included the virtual lab infrastructure used for the team’s development and testing. The team had to live with very slow response times until the organization could adapt with additional hardware resources. During this period of instability, the team was also adapting to new processes to create a new cadence for the “New Normal.”

Technical/Project Observations

The Technical/Project factor is consolidated from variables such as technical competency, domain knowledge, knowledge of the customer, project size, and the type of project, among others. Technical uncertainty, technical complexity, urgency, relative project size, specification changes, project criticality, and software development methodology also make up this factor (Garousi, Tarhan, Pfahl, Coskuncay, & Demirors, 2019).

The “New Normal” of remote work had little short-term impact on the development team. Whether working in the campus office or the home office, developers need concentration time and clarity of tasks to develop complex customer-based projects. Suitable WFH environments seemed to work equally well as office environments. When asked, developers cited several advantages and disadvantages to WFH. Many developers liked the ability to change their view, sit on the couch, use the dining room table, and not just sit in the WFH office. Conversely, they cited the disconnection from other team members as the most significant problem.

Knowledge sharing for software developers is primarily an electronic activity with sharing of files, code examples, and URLs from internet sources of knowledge. Much of this did not change with going remote. The use of Skype collaboration significantly increased to take the place of meeting up at each other’s cubicles. While voice, video, and instant messaging do not reach the media richness of in-person communication, enough communication effectiveness was obtained to see little if no performance degradation in the team’s delivery of value.

The difference and most significant impact on the development team from local to WFH was the asynchronous nature of much communication. While natural for remote work, the asynchronous wait time for a response is not a condition realized in the office environment where one can walk over to a cubical and get an immediate answer. The learning curve required the team to adapt to this “New Normal” condition. Several developers adapted by being more responsive, while others had to learn patience to get questions answered. Not everyone adapts well to being leashed to the keyboard.

Leadership Observations

Leadership consists of setting a vision with the team, communicating the mission to enable self-motivation to occur, and guiding the team as they construct what is needed for the project at hand. Successful leadership includes a clear strategic vision, total team alignment, and the ability to adapt to complexity (Shenhar & Holzmann, 2017). After experiencing local and remote leadership, leadership for a remote team is significantly more complex. Remote leadership requires a great deal more intentionality in communications and connections. Getting lost in one’s own tasks can result in the entire team lacking direction.

As the product owner for the development team, it became clear that attendance at the daily scrum or standup meeting was required to understand and guide the direction of work being performed. As the leader, responsiveness to questions, instant messages, and emails were important because delays for the team meant delays for the project. Adaptation to a “New Normal” became an imperative. Concepts were drawn from books such as “Crucial Conversations” by Ken Patterson (Patterson, 2012) and Simon Sinek’s “Leaders Eat Last” (Sinek, 2014). The “New Normal” in leadership included nearly instant responsiveness, near-continuous availability, and a significantly heightened evaluation of the emotional state of each team member.

The delivery of information had to change as well. Instead of being able to call the team together for a quick whiteboard discussion, PowerPoint charts had to be created, a meeting scheduled, and conducted remotely. While a Slack-style tool (collaboration product) would have helped with some of the collaboration, this type of tool was not available in our organization during that time.

Every video meeting, every IM, and every phone call was also a check on each person’s emotional state. When talking with someone, instead of thinking of details regarding the conversation, a new paradigm was constructed. The new paradigm is self-described as extreme emotional intelligence or Extreme EQ. While this may be natural for some, this is unconventional thinking for the typical introvert software developer. It is the very intentional focusing on the other party to best understand their state of being, which governs what they do, say, and think.

As a local team turned remote, to enhance our opportunities for collaboration, rules for engagement were adopted and implemented by the team. These guidelines included office hours, dress for your day (no PJs), and cameras on for video meetings. The intent behind the rules of engagement was to create some mental separation between work and home, to create overlapping work schedules, and to gage reactions to increase the media richness of communications.

Conclusions

Preconceptions to traditional on-site work need to be challenged in the “New Normal.” With training and adaptation, remote software development teams can be effective. Teams need to look for new ways to succeed, and some habits need to change. Moving from a co-located team to a remote team was hard; however, the team adapted and eventually excelled in many areas.

Adapting processes to create efficiency and flow kept the team engaged, focused, and productive. Unlike co-located work, remote work required intentionality with respect to communication among team members. Sometimes it was necessary to nudge or force the communication to occur to increase productive task conflict and resolve unproductive process conflicts.

Trust is foundational to all teams. Finding ways to build bonds of trust and foster our team's psychological safety was key to the success of working in a collaborative WFH team structure. Including pets as part of our team supported and encouraged collaboration and friendship amongst team members. Establishing guardrails as guidance, such as dressing for work and establishing work hours, significantly helped the team re-bond from home. Remote work as a team member was not for everyone. The isolation felt during the pandemic increased stress and emotional stability issues within the team.

Organizations were not prepared for a pandemic. However, new infrastructure investments were made to become productive during the hardship. New choices and capabilities are now available for WFH or hybrid work structures. The “New Normal” developed new capabilities and structures for working and collaborating. With “New Normal” policies, paradigms are shifting to improve local, remote, and hybrid work structures.

Leadership lessons learned include that transitioning from co-located to WFH is challenging, requiring enhancing communication, overcoming sudden isolation, and instituting productive work structures. Communicating with intentionality is also required to help build and sustain the shared mental model and team psychological safety. Tools used for co-located teams are significantly lacking when applied to remote users. Collaboration through current capabilities requires a great deal of effort to communicate effectively. Significant training and adaptation to localized leader techniques are required to survive in the “New Normal.”

The “New Normal” identifies weaknesses in localized teams. Utilizing knowledge gained through research, one can identify issues, mitigate the conditions, and adapt to the “New Normal.” Utilizing instant messaging and video tools intentionally and more frequently increases the media richness of communication. Driving the team to standard working hours helps with accessibility and decreases degree of dispersion. The “New Normal” is different, difficult, and distant. Adapting to techniques utilized in distributed teams drives commonality, community, and clarity.

References

Daft, R. L., & Lengel, R. H. (1986). Organizational Information Requirements, Media Richness and Structural Design. Management Science, 32(5), 554.

Driskell, J. E., Salas, E., Goodwin, G. F., & O’Shea, P. G. (2006). What makes a good team player? Personality and team effectiveness. Group Dynamics: Theory, Research and Practice. Group Dynamics: Theory, Research, and Practice, 10(4), 249-271. doi:10.1037/1089-2699.10.4.249

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

Eisenhardt, K. M. (1989). Building Theories from Case Study Research. The Academy of Management Review, 14(4), 532-550. doi:10.2307/258557

Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. (2021). The SPACE of Developer Productivity: There's more to it than you think. Queue, 19(1), Pages 10. doi:10.1145/3454122.3454124

Garousi, V., Tarhan, A., Pfahl, D., Coskuncay, A., & Demirors, O. (2019). Correlation of critical success factors with success of software projects: an empirical investigation. Software Quality Journal, 27(1), 65. doi:10.1007/s11219-018-9419-5

Guzmán, J. G., Ramos, J. S., Seco, A. A., & Esteban, A. S. (2011). Success factors for the management of global virtual teams for software development. International Journal of Human Capital and Information Technology Professionals (IJHCITP), 2(2), 11.

Hinds, P. J., & Bailey, D. E. (2003). Out of sight, out of sync: Understanding conflict in distributed teams. Organization science, 14(6), 615-632.

Hofstede, G., & Hofstede, G. J. (2005). Cultures and organizations : software of the mind (Rev. and expanded 2nd ed. ed.): McGraw-Hill.

Holmström, H., Fitzgerald, B., Ågerfalk, P. J., & Conchúir, E. Ó. (2006). Agile Practices Reduce Distance in Global Software Development. Information Systems Management, 23(3), 7-18. doi:10.1201/1078.10580530/46108.23.3.20060601/93703.2

Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook:: How to Create World-Class Agility, Reliability, and Security in Technology Organizations (First Edition ed.). 25 NW 23rd PL, Suite 6314, Portland, OR 97210: IT Revolution.

Park, B. (2021). DELIVERING VALUE TO THE CUSTOMER USING DISTRIBUTED SOFTWARE TEAMS : IDENTIFYING THE KEY RESEARCH FACTORS Paper presented at the ASEM International Annual Conference on Engineering Management, Virtual.

Patterson, K. (2012). Crucial conversations : tools for talking when stakes are high (2nd ed. ed.): McGraw-Hill.

Shenhar, A. J., & Holzmann, V. (2017). The Three Secrets of Megaproject Success: Clear Strategic Vision, Total Alignment, and Adapting to Complexity. Project Management Journal, 48(6), 29-46.

Sinek, S. (2014). Leaders eat last: Why some teams pull together and others don't (First Edition ed.): Penguin.

About the Author

Ben Park, Ph.D., completed his doctorate in Industrial Engineering with an emphasis in Management Systems at the University of Central Florida (UCF), Orlando. Dr. Park has a Master's degree in Engineering Management and a BS in Computer Engineering, both from UCF. Dr. Park is a software engineering and development leader with 30 years’ experience developing and deploying custom-built software solutions. As CTG’s Director of Software Development, he leads a team of software development professionals that build flexible solutions to meet the needs of enterprise clients across industries. Dr. Park is a proven, motivated, and enthusiastic leader that understands how to apply a strategic vision to practice, seeks and forms collaborative teams, and transforms groups into teams aligned to a common vision. Dr. Park is an award-winning technical leader with the knowledge to design large systems of systems as well as small, embedded devices. With a Ph.D. focus in globally distributed teams using agile software development, he has a clear understanding of what is needed to operate in multiple time zones, locations, and cultures.

Timothy Kotnour completed his doctorate in Industrial & Systems Engineering with an emphasis in Management Systems Engineering at Virginia Tech in Blacksburg, Virginia. He completed his Bachelor’s of Science in Industrial Engineering at Bradley University in Peoria, Illinois. He is the Lockheed Martin St. Laurent Professor in the Department of Industrial Engineering and Management Systems at the University of Central Florida. He is the Director of the UCF Engineering Leadership and Innovation Institute and the Program Director of the Professional Engineering Management Program. He is the author of the books “Transforming Organization: Strategies and Methods” and “Inspiring the Leader Engineer: Instilling the Burning Desire and Confidence to Change the World.” Dr. Kotnour has been awarded three NASA Public Service Medals (2016, 2005, and 2001) for the partnership work with the Kennedy Space Center. He is also a Fellow of the American Society for Engineering Management (ASEM). He was past editor of ASEM’s Engineering Management Journal.