Continuous Collaboration

The age of teams collaborating by huddling around a whiteboard in a meeting room inside some corporate office is dead. The future of teams is continuous collaboration. In this post I will explore what this is, how it works, and why meeting rooms and whiteboards should be consigned to the scrapheap of failed team collaboration approaches.

(Note: this is not to say that there isn’t sometimes value in meeting rooms and whiteboards for knowledge dissemination and other group activities, just not collaboration.)

Introduction

Post-pandemic there seems to be a growing trend of companies trying to force their employees back into an office environment. The figures don’t really make sense, particularly for engineering teams. Most high performing engineering teams that I have looked at have much better performance metrics in a mostly remote working environment than they did when office based. There’s clearly more going on behind the return to office push, but that’s probably a topic for a different post.

One specific argument I’ve seen repeatedly stated by management is along the lines of:

“We need teams in meeting rooms, using whiteboards, so that they can collaborate effectively.”

Prior to around 2018, I maybe would have tended to agree with this approach. Since then, and particularly post-pandemic, things have changed so much that I no longer consider this to be an effective approach to collaborative work. Let’s dive into why…

Why Whiteboard Collaboration Doesn’t Work

So, lets start with an exploration of how the legacy meeting room and whiteboard collaboration approach pans out.

The team decides they need to collaborate on some design work. To do that they will set up a meeting in the office and work through it on a whiteboard. They set up the session for the next day. Bob is pissed because this means he has to now come to the office on a day he normally works from home, and that means rearranging his childcare at short notice.

The day of the meeting arrives. Bob is still pissed. Alice is stressed and exhausted because her train broke down and she had to endure a 3-hour commute. Still, the meeting goes well. The team talk through the requirements and assumptions, draw out at great design and divide it into epics and tickets. Simon gets given the job to add these to their Jira board once the meeting is done - he’s not happy. They take a photo of the board and post it to the team Slack channel before wiping off the board ready for the next meeting room users.

Bob and Alice decide to pick up the tricky calculation part and agree to pair on that work, as this will reduce the risk of errors in the calculation. The other members of the team all go off and pick up bits of the development work.

The following day, Simon suddenly discovers that one of the key assumptions they made for the design is incorrect. This invalidates a bunch of the design and therefore needs some more collaboration to resolve. This is fine: agile development is intended to support this. The team agree to have another workshop meeting.

Unfortunately, the first slot where they can all get together is not until the following morning. However, none of the bigger meeting rooms is available at that time, so they schedule the meeting for the following afternoon. Alice and Bob can carry on work as their area isn’t impacted by the change to the assumptions. Other team members either have to stop their work and switch to something else, or decide to proceed at risk, knowing they will likely have to refactor a bunch of stuff once the new design is agreed.

The following day arrives and it’s time for the meeting. Alice couldn’t make it into the office due to an emergency at home. The team waste 10 minutes getting her connected to the video conference equipment in the meeting room so that she can hear them and see the whiteboard clearly. They then spend 10 minutes recreating the diagram from the previous meeting so that they have a starting point to iterate from.

The meeting goes well. The design is updated and the epics and tickets are reworked to support it. Bob reluctantly takes the action to update these in Jira. Everyone re-divides the work and heads of to start implementation. Unfortunately no one remembered to take a photo of the updated whiteboard. Simon discovers another problem with the new design…

New Developments

Prior to about 2018, the above was really the only way for people to effectively collaborate at team scale. Collaborations between individuals via pair programming and the like were possible and effective, but larger than a couple of people was always mostly limited to physical meetings or partly broken voice/video calls.

Then, all roughly at the same time, a whole bunch of things came together that provided a moment of transformation. These things included:

A new generation of video conference tools that supported multi-user, high quality, reliable voice and video conferencing combined with the ability to screen share at high resolution.
A significant improvement in laptop power and performance, including the ability to drive multiple high definition external monitors and the power to run video and screen sharing without significantly degrading performance of other applications.
Improved home broadband speeds capable of streaming large amounts of video concurrently while also being able to do high-definition screen sharing.
The increased availability of large (35"+), high definition monitors at a price point affordable to most developers (previously these were restricted to the realm of imaging professionals and dedicated gamers).
A bunch of new and improved online collaboration tools that allowed multiple users to work collaboratively, and concurrently, on the same document or workspace (e.g. Miro, Retrium, Trello, Google Office / Microsoft Office 365).

With all of these new developments combined, we were suddenly in a place where a whole new way of collaborating became possible.

What is Continuous Collaboration?

I first really started playing with continuous collaboration during the pandemic, when remote working became the required norm. It worked well. More recently our remote-first team have been using this as our primary model of working. It has been superb. We’ve collaborated more than ever before and both our productivity and quality have improved. We’ve also been able to react much more quickly to changes in requirements and new discoveries.

Let’s revisit the above scenario and how it plays out in a continuous collaboration model.

The team don’t need to take a conscious decision to collaborate on the design work. They are always collaborating. There’s no need to arrange a specific meeting space, the team just decide on a time when they will all be free to collaborate together. They decide that rather than wait, they’ll jump on straight after lunch and focus on the design - they can get moving on the implementation more quickly that way.

A couple of the team are in the office (see next section) and the rest are working remotely. This isn’t an issue. There’s already a team video call open from the morning and they all join that. They also fire up a new Miro collaboration board in another window and start to design.

As they are all at computers they are able to quickly look up information in real-time. They quickly discover that one of their assumptions is wrong when Simon messages a colleague in Slack and reviews the process document that this colleague points him to. This prevents going down an incorrect design alley.

At the end of the design session they have a shared Miro board that is automatically saved and that they can all continue to work from. They’ve also been able to populate the Jira board in real-time, so everyone can jump straight into implementation work.

Bob and Alice still decide to pick up the tricky calculation part and agree to pair on that work. They break out into their own separate call and usilise the “Code with me” function in their IDE. This means they can both work together on the same feature, even though Alice is in the office and Bob is working from home. Their multiple large screens mean they can see all the information they need visible to them at the same time (IDE, Miro, Slack, video chat, specification document) without having to context switch between windows.

The other members of the team all go off and pick up bits of the development work, but they continue to chat to refine their thinking, share ideas and avoid accidental duplication of work. As the thinking evolves, everyone updates the shared Miro board, Jira tickets and a live-wiki with new observations and details of all the small decisions that they are taking. They won’t need a stand-up tomorrow as the sharing of progress is continuous.

The following day, Simon suddenly discovers that one decision they made in the design is incorrect. This invalidates a bunch of the design and therefore needs some changes to resolve. Most of the team are online in a group call and have access to the existing Miro board. Alice is waiting for an imminent visit from the plumber at home, but she’s able to dial-in from her phone to listen in and offer contributions.

They therefore take a quick break and jump on together to correct the design. The correction is really easy as the Miro board is instantly available and reflects all of their current thinking. While doing this they also update the Jira tickets with the changed design details. In under an hour the new design is captured and everyone can continue productive work.

Key elements

From the above, we can highlight some key elements that make this continuous collaboration possible:

The team is mostly on a continuous video call all day, sharing thoughts and asking questions. Communication is high.
Most team members operate on open-mic all day, so communication is instant and there’s no need to keep fumbling around for mute/unmute buttons.
Individuals or pairs can breakout into their own calls to tackle bit of work, but everyone can easily get back together as needed.
Shared workspace tools mean everyone always has access to the latest state of designs and decisions and it’s super easy to carry on from that point rather than have to get everyone back up to speed.
Pairing tools mean people can work on the same code files concurrently and in real-time, which cuts down the need to keep merging work via version control. They can do this with their own IDE and computer/screen setup rather than trying to do this via a single shared computer, which is usually not ergonomic for either members of the pair.
Everyone has full access to the the information they need and to other resources via Slack whenever decisions are being made.
It really doesn’t matter if team members are in an office or remote, the collaboration happens regardless.
Good equipment and large, high quality monitors mean the team members can have many tools working concurrently and all the information they need visible at once. This reduction in context switching makes them go very fast.

How Does It Work in an Office Environment?

One of the advantages of continuous collaboration is that it can work well in any location. It doesn’t need all the team members to be co-located: in fact it thrives in a remote-first environment. There are however some specific requirements to make it work well in office based environments:

The office needs to be conducive to open-mic audio. This means that there shouldn’t be large amounts of background noise that will be picked up by each participant’s audio setup - a huge problem in noisy, open-plan offices. In practice this can be achieved through a combination of two approaches:
- Provide each team with their own closed office space. Only a single team works in each space, so the only noise is from the team. The use of a shared microphone and speaker system can make it possible for remote participants to be actively involved while allowing those members in the room to communicate naturally.
- Provide each team member with a high quality, noise filtering directional microphone and good quality noise cancelling headphones. They way they can breakout into their own calls or take some alone/quiet time without causing disruption to the team.
Ensure the networking infrastructure is sufficient. Multiple team members all running video calls, screen sharing and other online collaboration tools use a lot of bandwidth. Wired connectivity works better than wifi.
Make sure that the team is equipped with good quality laptops that are capable of running all of the tools and driving multiple high-resolution monitors.
Provide really large and good quality monitors (this applies to the home office as well). A couple of generic 27" monitors on fairly non-adjustable monitor arms just isn’t going to cut it.

Summary

Meeting rooms with whiteboards provide a mechanism for team collaboration. However the collaboration generated tends to be short-lived and difficult to restart. It also doesn’t work well when some members of the team are working remotely (or hybrid).

Fortunately technology has improved so much that we can now achieve an even better method of collaboration. It is now possible to collaborate continuously using video conference, open mics and online multi-user tools. This new way of collaborating is so effective at sharing ideas and improving productivity that being locked in a room with a whiteboard feels like being consigned back to the dark ages.