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:
- Wow I've never seen a team move this fast
- 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:
- Pick an owner
- Organize a swarm meeting
- Discuss how we're solving the story
- Write a list of subtasks together
- Work on subtasks in parallel
- 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:
- no surprises in pull requests
- everyone contributes
- people know how their work fits the bigger picture
- less experienced team members learn how to break down large chunks of work, fast
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.
- organize the swarm meeting
- translate the discussion into subtasks with rich descriptions
- work on subtasks
- liaison with the product owner
- verify final integration
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.
PS: you can learn more about the softer side of engineering from my Senior Engineer Mindset book
Become a *true* Senior Engineer
Get promoted, earn a bigger salary, work for top companies
Getting that senior title is easy. Just stick around. Being a true senior takes a new way of thinking. Do you have it?
Leave your email and get the Senior Mindset crash course - a series of emails on the mindset of a senior software engineer. What it takes to get there, what should you do when you're there, how to change the way you approach problems.
The Senior Mindset crash course
Get an email crash course on the mindset of a senior software engineer. What it takes to get there, what should you do when you're there, how to change the way you approach problems.
it describes my days in a way I have not read before.
This was a very enlightening article about being a senior engineer.
You write in a way that just makes sense. I found just about every idea valuable.
Senior Mindset Book
Get promoted, earn a bigger salary, work for top companiesLearn more
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️