Working Together

Lately at work we're trying something new, and I want to tell you about it, because Avdi says you'll find it interesting. It is one form of ensemble working, and it is one form of technical coaching, and it is one form of getting reality right in front of your face.

The usual way of working here is, user stories come in from the business and product owners. The team divvies them out to different people. They work on the stories, usually alone, sometimes in pairs. Cuz everybody has some knowledge about some of the software system. Often Thunsa here needs to call in the person who last worked on that segment, and then they pair.

Seem familiar? Pretty common scrummy workflow.

Yesterday I pulled the team together and said hey, for 2 hours, try something with me. It'll be interesting. (I'm officially a technical coach, so I can get away with this.)

We started with a user story, one that someone had already started on. Everyone checked out the branch on their laptop.

We did an unusual form of working together by, like, literally working together. We made a little rotation to take turns typing for 15 minutes, and the person typing is not supposed to make decisions. They enter the decisions into the computer. There's a person in charge of talking, and they lead the decisions, but everyone can contribute.

All those pieces of knowledge come together. Every decision is voiced, so everyone can keep up with what's going on.

So like, if it's Agon's turn to make decisions, and Laofor's turn to type, then Agon says "Laofor, please share your screen and open the code to relevantFile.ts" and Laofor is like "where is that?" and somebody knows.

and Agon says, "OK. Start up the app so we can see what it does now" and Laofor types "npm start" and then there's an error, oh that weird message means you need to be on VPN OK They do, and then the app starts up, and then Laofor is like, "why does yours look like that? Mine has text here" and Thulsa is like "Oh, you're missing these content files, let me zip those up and give them to you"

and then that happens, and 15 minutes later the app starts up and looks right and it's time to switch.

Sound painful?

This format of taking turns typing and talking, with all knowledge shared and all decisions voiced, is known as ensemble working.

Ensemble working can be smooth, when there's, say, one computer in a room where everyone physically changes places. Or one development server in the cloud that everyone can connect to. It's even smoother than this when you have one person set up the dev environment and everyone else controls their screen.

But I wasn't aiming for smooth. I knew this would be rough, because local environments are a challenge. As the longest-tenure developer on the team, Agon here has no idea how rough it is, because theirs works most of the time, and they know all the tricks.

Switching who's typing every 15 minutes makes Laofor's local problems into everyone's problems. And Thunsa, and Baobin, everyone's pain is felt by the whole team. This is a leveling. It brings help to the team members who need it most, and perspective to the ones who don't have the same problems.

For the last 20 minutes of the two hours, we stopped trying to code and had a little retro. One team member said, switching is a lot of overhead, we should do it less frequently.

And I said, thank you for that observation. Next time, let's switch more frequently! Every 10 minutes!

There's a saying in DevOps: "If it hurts, do it more." Because I want development to be smooth, and we won't get to smooth by going around the problem. If we pull back to make it hurt less, we won't cut down the thornbush. It'll keep getting gnarlier.

So instead, let's dive in there together. Let's help each other out, and work to dissolve these problems, instead of defeating them every day, over and over.

Is this more productive? No! Not for getting that story done. But it is more generative. It results in a stronger system, of team and software, a bigger symmathesy!

Everyone has a wider understanding of this story, some portions of the software, and -- this is crucial -- they have a more accurate view of everyone else's world. The team has more common ground, which is essential in joint activity.

For many teams, ensemble working IS the fastest way to get work done. For every team, ensemble working is the fastest way to share knowledge.

So far we've come out of every ensemble working session with some surprises, and a stronger team. For a cost of two hours, I'll take it. We will do this again. If you try it, let me know how it goes.