Asynchronous Teams Modus Operandi

How teams can scale throughput and collaborate better

A Synchronous Way

Interdependencies in software, particularly in ML, are complex. To deliver an ML-powered enterprise application requires several teams, with different charters and functional deliverables, to come together. As such collaboration between these teams to deliver their piece of functionality is strongly necessitated. The collaboration between teams is, at least in part, done in a synchronous way, with moderate to strong coupling. A common symptom observed is one team being blocked waiting for another team to complete their work.

The most perceptible side effect of this modus operandi is the introduction of involuntary bottlenecks and inefficiencies in execution. Another, less apparent, issue is the introduction of friction in the relationship among teammates.

An Asynchronous Approach

Operating asynchronously would allow for looser coupling thereby allowing for each team to work on the implementation of their respective systems and check on progress regularly. But what does asynchronous mean? And how to make it work?

The solution proposed begins with requiring a small upfront investment from the interdependent teams. At the beginning of each project or feature (henceforth known as task), teams would get together to:

1. Define the task: Establish a common understanding about the work to be done
2. Produce an architectural design of what is to be built and document the expected behavior of the system and its clients
3. If applicable, define the API contract(s)

This upfront investment will continue paying dividends for a long time: understanding of the work, alignment around what needs to be done, separation of concerns, documentation, and more.

The following diagram illustrates how the asynchronous workflow would work.

Figure 1: Loosely coupled asynchronous collaboration.

Teams A and B would meet at the beginning of task X, define the task and write down the specs. Each team would work, with a fair degree of independence, on the implementation of their respective portions of the work, and at their own pace and availability.

One possible scenario is that Team B finishes their implementation before Team A. In this case, Team B would put the work on hold (press pause) and switch context to another task (task Y), while they wait for Team A to complete their implementation. Once Team A is ready, Team B would switch context from task Y back to task X and finish the integration with the work from Team A.

This modus operandi does not come for free, there are costs and challenges to its implementation. Active participation of leaders is necessary to mitigate those risks and to make the benefits much higher than what they cost. This requires a coordinated effort from team leaders to adopt and apply this practice successfully.

The Costs of Switching Context

Switching context between tasks is an expensive operation:

1. Latency: two or more tasks are in-flight and unfinished
2. Stress on engineers: risk of losing mental flow, morale, feeling of leaving a task incomplete
3. Sacrifice the velocity of the current task; regain momentum on the task that was paused

These costs can be mitigated or eliminated if expectations are set and managed properly. The switching of contexts cannot be abrupt. Instead, it must follow a protocol.

One of more of the following conditions must be met in order to allow for switching of context:

1. The task at hand is in a state where itself can be put on-hold
2. A predefined milestone has been reached
3. The sprint has ended
4. A criteria established by you and your team where agreement for context switching is universal

Under no circumstance (unless a critical emergency that may threaten the business) an engineer should be asked to switch context “now.” You and your team would be incurring all the costs and collecting none of the benefits. This action alone would single-handedly erode everything.

The Benefits of Asynchronicity

A notable benefit is higher throughput, which leads to being able to scale the team better. Sprints can be planned more flexibly and operations of each team will consider internal projects and priorities, combined with external (cross-team) commitments. This modus operandi allows for a higher efficiency.

Another benefit is the improved relationship between cross-team members, as the work is loosely-coupled and there is mutual understanding of the asynchronous nature of the implementation and integration.

Last, but not least, this approach naturally yields to more modular and decoupled code and stronger, enforceable, API contracts.

Accountability

A risk exists that tasks may repeatedly miss deadlines or be deprioritized. Communication and accountability between teams becomes paramount. It is suggested that at the end of each quarter teams get together to take inventory of all tasks worked in collaboration: what has been completed, what is in-flight, and what has been delayed and/or not started.

Final Thoughts

Success will require a coordinated effort among team leaders and team members, no team alone will be able to make this work on their own. Let’s talk amongst ourselves, let’s share the proposal with the members of our teams, let’s hear feedback, and let’s combine it all to continuously improve this ever-evolving process.