Agile 2: A New Model for Embracing Asynchronous Communication and Remote Work

Agile purists often recommend that everyone in a team should sit together whenever possible to maximize collaboration.
One reason is that “osmotic communication” will occur. People will hear things and have important awareness of what is happening. Although it may seem accidental, such communication can accumulate and it can be very important.
Another reason is the assertion in the Agile manifesto that face-to-face conversations are the best and most efficient way to communicate information to and within a team of developers.
We believe that Alistair Cockburn is the source of this Manifesto principle. He had been using it almost exactly in those words for many years before the Manifesto was created.
Each of these ideas has a kernel of truth, but they are flawed. These are terrible oversimplifications, so bad that they can lead to poor choices about work.
Agile 2 embraces synchronous communication
Communication is essential for members of a team. They must also get work done. If their work involves deep or creative thought, they must focus. To focus well, people need protection against distractions. Sitting together allows for collaboration, but it can hinder focus.
Although we won’t say sitting together encourages collaboration, studies have shown otherwise. In fact, it appears to decrease collaboration.
Collaboration is only one aspect of what work is all about. Most people who design and build tech products have to work in a head-down, solitary environment. They also need deep thinking and creative thinking. Talking to people is a distraction from your ability to focus and deep thinking.
This means that people must be able to focus on their tasks without being distracted. It is important to turn off osmotic communication.
Face-to-face communication is not universally the best because it is an event-oriented view on a continuous and multidimensional process.
If you want to know something simple, then it is faster to shout to a few people to ask, “Hey Susan! Is the customer ID field string or an int?”
If you have to decide collectively on a strategy to combine and test changes to multiple product component components, some of which were produced in-house, then a side-of the desk conversation won’t cut it.
Even a group meeting won’t be enough, especially if it is the first time the team has had to deal with the issue. The problem is that the issue is complex. There are too many parts.
It is unlikely that any one person will have the opportunity to express their views fully in a one-hour meeting with the whole team, maybe seven or eight people.
We’ve seen discussions on this topic, and they often get sloppy. Facilitators must be able to comprehend the subject matter or they will lose their way.
Sciences deal with complex topics. One presents a paper at a scientific conference without being interrupted. Other papers are presented, sometimes with competing points of view.
After the paper is finished, there will be breakout groups to discuss it. After everyone has had their say in its entirety, and they have also written their thoughts down, collaboration takes place.
Jeff Bezos famously makes his staff write a “six-page, narratively-structured memo” for each meeting, and he says that it was the “smartest thing we ever did” at Amazon. He encourages his employees to think deeply and not engage in shallow, circular debates.
He believes that complex problems require structure.