Small Batches
Hey!
Welcome back to another week of musings.
I hope you had a restorative weekend! We spent the weekend visiting some friends and attending the Cherry Blossom Festival.
Was this forwarded to you? You can subscribe here!
Things I discovered in the past week
- I got my first Traveler's Notebook! Random product, but lately I've been enjoying writing on paper, and these things started to pop up on my YouTube feed as of late, I ended up buying one.
- Everyone’s an engineer now: Inside v0’s mission to create a hundred million builders | Guillermo Rauch (founder & CEO of Vercel, creators of v0 and Next.js), I've always been a fan of Guillermo Rauch (Founder/CEO of Vercel), so it was interesting hearing his thoughts on AI.
If you've ever tried to improve the velocity or predictability of your teams, you have had to deal with reducing the size of work, e.g., stories.
How do we reduce the size?
Generally, in agile practices, they'll tell you that doing spikes before working on a story helps reduce its uncertainty.
Some of the resistance I've heard from spikes is that "we're doing spikes all the time," or that "if the story is small, and while doing the spike, I end up doing the work." This might signal that the team avoids the estimates and wants to go straight to coding.
Teams might be bound by constraints, like the lack of a feature toggle platform, so they can only release in big-bang approaches, an all-or-nothing release type. This increases the complexity of estimates because you cannot incrementally release a feature, only a fully developed feature, but it is also tied to a service deployment.
Other times, the team associates spikes with doing the work itself, and until they hit a roadblock, document that. But spikes should be about answering a specific question uncertain for a feature. For example, if you're migrating from Express to Fastify, you might have never done that. So you'll spike for one hour if there's prior art somewhere on the internet about it.
Other Actors in the Chain
Other times, a given story might need the participation of different teams, such as a separate QA team that tests individual features.
This makes even small changes harder to estimate if your team doesn't control the other team's work queue. In this case, changing the culture might be an uphill battle, but it will be worth it in the long term if the developers are owners of their destiny regarding their feature development work.
The Point is Learning
If you've read the Fifth Discipline, you'll know that the learning organizations are the goal for companies that want to compete out there!
The feedback loop that working in small batches produces is much "tighter" than those that do weekly, monthly, or quarterly releases. If you've read Accelerate, they mention that high-performing organizations deploy multiple times daily. More important than the number of deployments, they're learning something with each release, making minor adjustments as they go, allowing them to keep velocity.
So after each iteration of work, as a team, you should learn which stories were estimated more accurately than others, what made those difficult to estimate, how much we missed, etc. After some iterations, you should be shipping safely and constantly!
Your turn!
Have you noticed if your team has multiple stories in progress or carries stories from sprint to sprint? How have you dealt with this, or did you even consider it? Let me know by replying to this email!
Happy coding!
website | twitter | github | linkedin | mastodon | among others