From soloists to ensemble
Giorgio Sironi - Tech Lead Manager @ eLife
(if you're reading this on your laptop, press S for notes)
A practice that is all about letting people work together rather than separately. Initially named mob programming, but after a couple of years of adoption my team has settle on the metaphor of a musical ensemble.
Giorgio Sironi (@giorgiosironi )
Tech Lead Manager
Problems I work on
Finding out the right piece of software to build, then build it
Give enough challenges to people
Growing enough basil and parsley
In those three words you can see I work with the team as a tech lead, writing code like everyone else. There is also "manager" in there as part of my job is helping people be a productive, happy team member and progress in their career.
Besides growing software, and growing people, I also try to grow some plants. In this phase I find the organic growth metaphor more realistic than all the software engineering ones I've encountered over the years.
Metaphors
And talking about metaphors, there are some concrete rules to follow when practicing ensemble programming. But even if we were to work all together on a piece of code during this talk, it might not get across the spirit behind them that makes them powerful, and adaptable to new contexts.
All the brilliant people working on the same thing, at the same time, in the same space, on the same computer. -- Woody Zuill
There are some constraints placed on a group of people to say they are working as a mob. They must be working on the same piece of software. They must be working in the same hours. They must be in a space where they can communicate synchronously with each other. And, given how linearizable committing code is, they should all work on a single working copy of a repository at a time.
For an idea to go from someone’s head into the computer, it must go through someone else’s hands. -- Llewellyn Falco
Driver: Hands
Navigators: Heads
Designated Navigator: Voice
Being together doesn't necessarily lead to a productive result without building in some facilitation rules. To make everything that happens explicit and visible, it can be agreed by the group and verbalized to a "naive" driver. A (often quickly) rotating Voice connects the Heads to the Hands, and ensures what's happening is understandable to the group. The Voice having to find consensus across the group on what to do next cannot be underestimated: they are channeling rather than leading.
Credits
Where do these names come from? A rally driver taking instructions from a navigator on where to steer or how fast they can go. Focus either on how much to accelerate and steer, or on the road ahead and what curves are coming. The driver can't go off on their own. Extensible from pair programming to an ensemble.
Credits
Mob programming is an established term, but it has often heard negatively - no one wants "the mob" to help them solving their problems.
When there is a big fire to fight, or a difficult problem to solve, often group of cross functional group starts to swarm against the problem. This name does not consider the facilitation rules of drivers and navigators though.
Credits
A metaphor that is seen a wider usage nowadays is that of a musical ensemble. People have (overlapping) specialties: the violinist can read music the same as the cello player. They must all be playing together in the same space at the same time and with great harmony for a good result that is more than what each of them could achieve alone. This is different from an orchestra that has a conductor as a single point of failure.
Credits
Moreover, navigating and writing code are only a couple of the things that happen in an ensemble. Whether we realize it or not, we are often playing various roles that are not producing code directly; I think of them as hats to wear for a certain time. For example, a Nose notices smell in the code; an Archivist takes notes in an architectural diagram or TODO items for later; a Sponsor makes all the voices heard.
Recognizing roles and naming them helps as a pattern language, in the same way as we recognize architectural patterns in code like a Factory or a Domain Event.
The remoteness of it
These practices may have assumed a co-located team when they were named. Remote teams like mine have become very common. What changes when everyone is joining from a different location?
is sharing their screen
has the only keyboard and mouse
uses their favourite IDE, setup, and chair
might not see all faces
In a physical space, there is usually a single workstation attached to a projector; the driver has to adapt to a new keyboard, maybe IDE. In a remote space, it's more about individual people sharing their environments than everyone adapting to a lowest common denominator.
is explicitly collecting group input
Does anything really change for the Navigator? The hard problem here is one of group coordination and synthesis of actions at the right level of detail. This is very verbal and visual, like seeing body language.
Digital-only boards are wonderful: shared across the ensemble, open to real-time collaboration, infinite in size, infinite post its, heterogeneous (screenshots and icons and text and post its), lowest friction to represent tasks/options/decisions visually. They solve the problem of visualizing process, as every action we take starts from some place on that board and everyone is continuously looking at it.
The flip side of an infinite visual medium. In an ensemble, whether it's violinists or software developers, there is ironically contention for one communication medium: the single audio channel.
In large physical workshops (say Eventstorming) there can be casual side conversations that happen concurrently. This is not possible in a video call unless people are organized with explicit rooms.
In the ensembling context, we work a lot on coordination so side conversations are not what we are looking for. We want one conversation, but we need to moderate how to speak. The problem of overlapping voices is exacerbated and experiences vary: due to different latencies, someone might hear overlapping voices where you don't. There's many ways to solve this, for example people explicitly handover to a person that hasn't talked yet: "...and this is what I think of this function. Mark?"
I found this experience superior to what we could have achieved going to a meeting room everyday.
The theory
Or fancy names given to the patterns and practices that emerge, or are elicited, by ensemble programming.
This is something you don't want to do. The industrial logic coaches named this anti-pattern to collaboration.
In this model, work is broken down into tasks and scattered across a group of specialists people. Every individual task has no value of its own, and every individual has their own queue of things to do. Maybe they are even measured by how "productive" they are. But reviewing and rework take a long time to happen, and we are optimizing for the utilization of people rather than to achieve valuable results.
We don't have to work this way.
In this swarming model, everyone is around. We select the most important thing to do now. Let's work on it together, finish it and move on to the next.
Your specialty might not get completely used all the time. But there are ideally no waiting times as everyone is available in the room to take decisions, even a designer or product manager. Even when someone is unavailable, by working together and building the same shared mental models we get a widened bus factor; there is no silo that is off limits and should not be touched while someone is on vacation.
This feels very Lean: reduces WIP in the queues and optimizing for value.
Every time you mention pair programming, especially in very hierarchical context, someone will say "isn't it wasteful?"
You can get a lot done on your own. But what if there is a lot of work in this area, and we need more people to work on it? Are you the only one that can touch that code, forever? How difficult it feels to have to take all the decisions? And make lots of assumptions to be verified or reviewed later?
Multiple contributions from an ensemble can lead to a better result. We see this as everyone either contributing or learning. From stepping on each other's toes to making a mosaic of good ideas. You can lose hours on a problem that another person would know how to solve in seconds, or know how to avoid in the first place.
Needless to say, this goes hand in hand with continuous code review over the rework that would happen on feature branches after comments arrive. It is enabled by trunk-based development, and it allows Continuous Delivery.
Where two programmers go faster and product a higher quality result than one, what about three, or four?
You can still work outside the ensemble
Deliberate learning
Spike branches
Just go for a walk
You don't have to be talking continuously, or in a video call, for the rest of your working life. There are problems that are suited to your own exploration or specialty, and where summarizing for the ensemble can be helpful to everyone. It might take the form of talking through some post its, or a branch with half-working code to demonstrate a new technique. But it's important to understand how exhausting it can be to continously interact with other team members with a prolonged, very productive focus. Energy can recouped by solo time, but imagine if you were working alone every day - that would be a nightmare.
All the brilliant people working on the same thing, at the same time, in the same space, on the same computer. -- Woody Zuill
So this is how we worked for the last two years, with a team growing from three people to seven and some changes along the way, completely remote.
Thanks for your attention!
Resume presentation
From soloists to ensemble Giorgio Sironi - Tech Lead Manager @ eLife (if you're reading this on your laptop, press S for notes) A practice that is all about letting people work together rather than separately. Initially named mob programming, but after a couple of years of adoption my team has settle on the metaphor of a musical ensemble.
.jpg)
.jpg){kind=link}
