A quick post from #lkin17 – Synchronous vs asynchronous: which is better?

A quick mid-conference post from Bengaluru and Lean Kanban India 2017. This morning I gave a repeat what I thought was a one-off talk, the provocatively titled “Scaling without cross-functional teams”, a title set me as a challenge by the organisers of Øredev 2016 (video of that original session below).

Scaling without cross-functional teams from Øredev Conference on Vimeo.

A nice little paradox occurred to me as I was wrapping up today’s talk: systems are often more performant, more robust, and more manageable when they communicate asynchronously, and yet Agile is founded on collaboration and therefore highly dependent on synchronous forms of communication. We want people to be working with each other, talking to each other, face-to-face if possible.

Which is better? Synchronous or asynchronous? Of course neither one is intrinsically better; it’s important to understand the costs and benefits of both in context and choose appropriately. Often a mix of styles is required:

People working mostly independently (communicating only as required) or in pairs (communicating all the time); the team comes together daily to synchronise.
As work items change status, it is signalled on the board (allowing an asynchronous response). Key events such as planning and deployment bring people together to coordinate and may cause multiple work items to move in tandem.
Communications arising from things happening outside the team generally arrive unpredictably. Mostly of the time, the team responds only when ready, if indeed it needs to respond at all. Similarly, the team will from time to time issue announcements or requests without any reliable expectation of how they will be responded to (if at all). Whatever the direction of the communication, some situations will require a synchronised response (eg a meeting) when (say) email is no longer the appropriate medium.
Typically, well-engineered business applications can started, stopped, and upgraded at will, independently of other systems. The ability to do so makes them much more manageable and enables a significantly faster rate of change. This isn’t just a technology issue; it also requires people to deal appropriately with those cases in which it seems that multiple systems must be upgraded together because guarantees of backward and forward compatibility will be broken. With good architectures and a degree of proactivity and forethought however, these situations (dependencies) can often be managed away painlessly behind the scenes.

If there’s a general principle here, it’s that synchronisation is a good default at small scale (eg pairing, standup meetings) but that asynchronous communication soon becomes the more efficient default as systems get larger, beyond the size of a single team or application component. Self-organisation is possible at these larger scales; even 20 years ago I was working in environments that could roll out changes affecting multiple systems, multiple sponsors, dozens of people, billions (yes billions) of dollars worth of business, and not a single project manager in sight. It can work!

We have a name for large-scale systems that rely significantly on large-scale synchronisation, featuring combinations of coordinated releases, management approvals, stage gates, complex schedules, frequent large meetings, and large documents that few people want to read: the word is heavyweight. Yes that’s a loaded term (pun 100% intended), but I would only choose to engineer a heavyweight system of any kind (process or application) if I were sure that the alternatives were worse. As far as I can recall, I don’t think that has ever happened. There are usually faster, cheaper, higher quality, and more humane ways of getting things done, even at scale.

See also: A True North for Lean-Agile?