Pitfalls of agile remote development and countermeasures for effective collaboration in geographically distributed teams.
Table of Contents
Remote work and remote agile development have been one of the remedies in this day and age of the Corona consequences. During the last weeks, I have come across several articles, posts and blogs about the pitfalls of remote working teams and recommendations on how to take countermeasures against missing collaboration.
I think the McKinsey article on “Revisiting agile teams after an abrupt shift to remote” [1] is an interesting contribution worth considering. I am going to refer to some other sources, but do not claim any completeness with respect to the topic. But across all articles, I have been missing some simple but effective means of not only promoting a more collaborative mindset but making cooperation actually happen.
I am especially mentioning the McKinsey article since it presents some figures from a study from 2017 done by Harvard Business Review (HBR) [1] on the opinion of remote workers about their co-located co-workers. The HBR study surveyed “1,153 employees, from which 52% said they work, at least some of the time, from their home office”. According to that study (from 2017!), 41% of remote employees answered that “colleagues say bad things about me behind my back”, compared with 31% of on-site employees. And 64% of remote employees believe their “colleagues make changes to projects without warning me” against 31% of on-site employees. Additionally, 35% of remote workers also said that “colleagues lobbied against me with others” versus 26% of on-site employees.
These figures were astonishing to me! Break it down to your situation: it is almost every third of your on-site colleagues. And this number surges to 41% for remote workers. The German post on “7 Tips to make IT enterprise more successful” [3] in current times, also mentions remote work as an opportunity for software developers to work in a focussed way since development is a substantial cognitive activity. But it also says office politics and gossip as one of the main challenges to avoid, e.g. by hiring people resisting this kind of activities.
So I have been wondering how remote agile development could ever work. Especially since it adds to the personal unease of mine spread by such posts like “Spotify doesn’t use “the Spotify model” and neither should you” [4]. It includes the statement that “collaboration was an assumed competency”. And it indicates to me that people do not collaborate “out-of-the-box”, it seems that collaboration needs to be learned, experienced and reinforced in an agile team. Furthermore, giving feedback is another significant skill for collaboration. After joining a webinar about “Feedback – how to do it right” by Heinz Staber, an agile coach [5], I have just realized again, that it takes time to learn and time to achieve some level of personal maturity to do it right without effort.
One of the general recommendations of the McKinsey article is to “cultivate bonding and morale”:
Agile teams working remotely may also require a more deliberative focus on empathy, openness, respect, and courage. For example, team members may need to remind themselves to create and receive communications with a collaborative mindset and always to assume the best possible motivation from their colleagues. This practice is important to agile teams in general but to remote agile teams in particular, given how easily electronic communications can be misunderstood. [1]
Some more precise recommendation of the article how to promote a collaborative mindset is to “establish virtual happy hours” and “agile team leaders … (who) need to be closer to — and more proactive at — guiding their own team members.”
But I am missing one point here. A collaborative mindset is just the beginning. What we want to see is that collaboration really happens in a remotely working team regarding the significant mental obstacles listed above. Only actual collaboration and cooperation results in empathy and trust in each other.
How do we encourage people to cooperate? Who is going to start doing it? How can we let other team members see it happen? How we make them feel encouraged to join or to look for a remote co-worker to start cooperating themselves. Thus, we need
Interestingly, the authors of the McKinsey article [2] ask for similar things to have a remotely working team engage customers and external stakeholders:
What kind of similar techniques are well-suited to engage developers in real collaboration and cooperation?
The smallest possible sub-team in a team is a “team of two”. Why does “two” fit well? Several studies like the one mentioned by another Harvard Business Review article about “When small teams are better than big ones” [6] indicate that small teams, and particularly teams of two, are the best team size when it comes to innovation and disruption. And why do we mainly use agile approaches nowadays? Because software development turns out to be mostly about innovative products and services, and have to deal with uncertainty to a large extent, either about what the final product or service will look like, or due to a variety of changing technologies to develop software.
The communication in a team of two is ideal, direct by nature and without the overhead. Each team member is allowed to work on one’s code as long as there is a medium portion of commonly worked-on code. This does not necessarily come down to pair programming. It only requires working on a set of code modules together. Each person learns the coding habits of the other person, her/his way of thinking and coding style. They start talking about it to clarify open issues and to agree on some rules. There is enough freedom of separate coding for each of the two. Knowledge sharing and cooperation are made as easy as possible, more probably leading to bonding, personal trust, empathy and respect. This kind of cooperation is “effective collaboration” by “1-1 calls between developers”.
Cooperation, as soon as it arises, has to be made visible to others as role models. This is the part about “providing transparency”. “Live portals” could be implemented by using the code repository as a data source. Either you do some scripting on your own or use open source tools like Gource [7]. Alternatively, you can apply more sophisticated approaches like our DETANGLE Knowledge Analysisdealing with several kinds of knowledge distribution risks and visual patterns like knowledge islands or knowledge balances.
But you might be still inclined to say something like: “Well, teams of two sound reasonable. And it might emerge naturally since bonding and cooperation always starts with two people. But what if it does not happen? How can we initiate it, trigger it from outside or accelerate it?”. Well, agile team leaders have been mentioned above as well. They are the right persons feeling responsible for making cooperation transparent and point to good examples of cooperation by teams of two. There is also the need for agile technical leaders taking over the coordinating part of the development.
Let me call these persons technical coordinators. They organize major development work by working together with several other people to a small-to-medium extent. They make up “small” teams of two. They prepare code, provide code templates or examples, review and adapt code and suggest improvements. According to our experience and analysis, usually, one or more coordinators naturally arise in any software project. The persons and numbers or the extent of joint work with several other developers might vary over time, but any project not having these coordinators misses a fundamental principle of success, the necessity of one more agile leaders as role models in a project. Precisely, these leaders are the ones to feel responsible for suggesting teams-of-two to take over the work. And to make this team-of-two feel responsible for some initial work to be continued by the person they worked together and another joining co-worker.
Example: Teams of two and coordinators of Django Developer Community
The picture above visualizes the cooperation within the Django Web Framework developer community. Small circles represent developers and rectangles are source files. Developers are connected to source files on which they have been working. This kind of live portal makes cooperation transparent. Next, all the bigger red circles point to the source files changed by teams of two. Besides, there are two coordinators cooperating with several other developers within teams of two. And finally, the red rectangle suggests two developers building up a new team of two after having been guided by two coordinators.
Both, coordinators and teams of two, are also means of avoiding a problem rather known from bigger teams. It is called “social loafing” as described in “Why less is more in teams” [8]. I can imagine it posing a risk for remote teams, too. People do not only appreciate the trust, respect and empathy by other people but also have a strong sense of fairness. It is easier to get to the impression of colleagues practising social loafing due to remote workplaces, either justified or not. Teams of two are the first-level countermeasure of such occurrences and the active work of coordinators the second-level support in integrating and involving people. Live portals are also an essential visual supplement. These make ongoing cooperation of teams of two transparent and evident as role models. And show the coordinators practising cooperation by example. At the end, let me confess something. We do not need to restrict ourselves to teams of two. I am happy to see teams of three or four as well. We do not need to be dogmatic 😉
Feel free to let me know your thoughts.
Cape of Good Code identifies different groups of key developers and the overall distribution of effort and knowledge within a Sofware Due Diligence.
The number one pitfall in developer stack ranking is to evaluate purely competitively and ignore collaboration. And secondly ...
Data-based analysis shows that Collective Code Ownership can do harm and affected code areas can probably become hotspots of maintenance.