Reader Question: What do collaborative teams look like?

Fellow reader Jeremy wrote in with a question:

How many people do you have working on one story at a time? And what does that actually look like? Mob programming? How do you figure out who “owns” something and ensures it gets finished when async time comes?

It was a comment on a reader question about the perfect burndown chart, which was a follow up on how we made the best burndown chart you've ever seen. We've since achieved an even better burndown chart, ending a whole 2 days early 💪

Then we got too big for our britches and well, ouch. Anyway,

Jeremy asks good questions. What does a collaborative team look like?

When new folks join our team invariably say 2 things:

  1. Wow I've never seen a team move this fast
  2. This approach feels weird. I'm uncomfortable

Teams like this are not common.

It's my first time working this way in ~17 years in the industry. I think the practice is growing but that could be observation bias on my part.

How many people do you have working on one story at a time?

I've been part of this team for 2 years now. Other than the manager who introduced this approach, I'm the only founding member left. Startups be like that.

Some folks left, others moved to new teams within the company. Rocketshipping 🚀

The team has waxed and waned. At our biggest we had up to 8 people working on a story, at our smallest it was 3.

Work feels the smoothest when there's about 4 of us.

This makes sense because psychologists say you can't have 1 conversation larger than 4 people. When your team grows beyond 4, it splits into two fluid teams in a trench coat. It becomes somebody's job to keep the team synced. Usually a senior engineer who gets nothing done.

That doesn't mean a bigger team is slower.

And what does that actually look like? Mob programming?

The day-to-day reality depends what we're working on. A gnarly bug that's wrecking brains can have 5 people on a Zoom working together. A straightforward make-new-page story can mean folks working on small pieces and assembling later.

Here's the general flow of stories:

  1. Pick an owner
  2. Organize a swarm meeting
  3. Discuss how we're solving the story
  4. Write a list of subtasks together
  5. Work on subtasks in parallel
  6. Assemble
  7. Verify and hand off to product owner

Swarm meetings are the mob programming portion of our approach. We all design a solution together, hash out any disagreements, explore alternatives, and create a list of Tasks To Be Done.

Ideally we define contracts between modules/functions/subtasks in a type/contract driven development style. We're working on this muscle. Easy to forget and be frustrated later 😅

This has multiple benefits:

Turning blobby requirements into discrete tasks is one of the hallmarks of a true senior engineer. The faster new members can learn that, the better.

How do you figure out who “owns” something?

We use rotating story ownership on a volunteer basis. When you feel ready to flex in a non-technical direction, we cheer you on.

The story owner acts as our project manager.

For bigger stories this can be a whole job. Making sure everyone understands the product owner's wishes, propagating any changes, and verifying the implementation works before asking the PO for final sign-off can mean you don't get to write any code this time.

And that's okay. You're the core of a surgical team. The person with all the responsibility and less of the work.

Who ensures it gets finished when async time comes?

The story owner.

Cheers,
~Swizec

PS: you can learn more about the softer side of engineering from my Senior Engineer Mindset book