Murmurations at Drip
Jul 9th, 2021, by Tamara Temple, Staff Software EngineerMurmurations
The following video shows what is known as a murmuration of starlings, where the birds flock and swoop in some kind of formation:
Murmuration from Islands & Rivers on Vimeo.
From the dictionary, a murmuration is a flock of starlings. Wikipedia has a little more info:
During the winter months, starlings are known for aggregating into huge flocks of hundreds to thousands of individuals, murmurations, which when they take flight altogether, render large displays of intriguing swirling patterns in the skies above observers. — https://en.wikipedia.org/wiki/Flocking_(behavior)#In_nature
Most dev folks have heard about pair programming, a part of Agile Programming, and some have heard of mob programming, which expands the pair to more than two people. An apt description by Marcus Hammerberg:
The basic concept of mob programming is simple: the entire team works as a team together on one task at the time. That is: one team – one (active) keyboard – one screen (projector of course). — from “Mob Programming — Full Team, Full Throttle”
Where we started
Here at Drip, we do some pairing, and some teams do mob programming when it makes sense.
My team at Drip is responsible for providing recommendations, insights, and suggested actions to our customers, generically known as Guidance. We’ve been given the opportunity to experiment and discover what works best for our customers.
At the time I joined the team, I was a contractor. About the same time, a new college hire was also joining the team. This felt like an ideal opportunity to use the multi-person approach in order to help both of us come up to speed quickly on the code base, and for our new engineer to learn the Ruby language, and Rails framework.
We worked really well in this mode, and started using it as other features that came our way. It was great to have someone with a lot of experience navigating and observing, someone with less experience driving, and other people to join in to provide answers in different areas.
What changed?
However, on Jan 6th, 2021, the mob attack on the US Capitol gave us a different feeling for the word “mob”.
Along with notions of “mob rule”, “mob violence”, and the general negative connotation for “mob” at least in the US and Canada, we found it quite distasteful to keep using that term for how we worked. We wanted to keep working in the helpful and productive way we had been, but lose the word.
We spent a few minutes sort of talking about the word, and no one was really coming up something, and I recalled the term “murmuration” from several years ago when I saw a video of one, captured by a couple women on film.
Where we’re at
From that point in January, our team has been murmurating for a big chunk of our work. The reasons why we started at the beginning don’t apply so much anymore, but the multiple heads on one problem is really a solid practice, especially when we’re tackling things that are brand new for us. By no means is all, or even most, of our work done in a murmuration, though.
Murmurations tend to happen:
- when someone needs help on a ticket
- when a ticket is particularly gnarly, possibly going into an area that has not been anticipated
- when we want to learn and spread knowledge to the team (e.g. a key player in a specific tech was going to be out for a month – yay sabbatticals at Drip! – so they ran a few murmurations with others driving so we could get a feel for the language and code base)
- if the action might be particularly dangerous if done incorrectly (e.g. we like to have a couple people doing a database migration in production)
When there’s a bug in production that’s causing a major issue for customers and we can’t figure it out quickly, we still use a team, but it’s more a swarm (i.e., all working simultaneously towards a solution, but not necessarily together) than a murmuration.
When someone picks up a ticket to work on and they’d like help on it, they post a zoom link in our Slack channel and invite team members to join them. Most often someone does. Also, team members will regularly ask if there are any murmurations going on when they start the day, come back from lunch or a meeting, or have some momentary down time as they decide what to work on next.
Even our weekly planning time seems like a murmuration as the whole team is involved in defining epics and stories, with one person driving by writing it all down in Jira.
During programming murmurations, the driver is rotated so we all get time in the driver’s seat as well as doing the observing or navigating role. This is quite helpful in alleviating fatigue and keeping everyone interested. Navigators can spend time providing context, history, and direction; some help by looking up documentation on syntax, libraries, method signatures, etc., to explain things to everyone. Everyone has a role, no one sits back and coasts. I believe this has a lot to do with how much we respect each other and also want to help each other.
Why is this important?
Some could say “it’s just a word, just a name. Why bother changing it?” That is a good question. The answers are partly practical, partly philosophical, and partly visceral.
As mentioned above, the word “mob” took on tremendously distasteful connotation for our team, yet we were highly committed to the activity entailed.
The beauty of a starling flock’s murmuration strikes a chord with people; they are more than just enjoyable to watch, they are stunning displays of nature’s beauty.
Using the term to refer to our work together provides a sense of that same synchronicity, swarming in formation together, without it needing to be defined, frame-worked, or even necessarily taught. It is experienced.
It is such a positive word, there’s a little spark of joy every time someone uses the term, even creating new forms, such as “murmurating”, and several folks just get a smile on their faces when we talk about it in zoom meetings.
The positive sense of the word murmuration forms the feelings people have about working together in this fashion.