How to Create a Good Release Process 🚚
A thorough guide about shipping fast.
Last week I published an article about Scrum, which got an incredible response 🙏
I received so many emails from readers with stories about their dev process, how they tweaked it over time, what worked for them, and what didn’t.
This week’s piece is, in a way, a follow up to last article.
In one of the comments, Kent wondered why teams sometimes work on 2-week cycles instead of—seemingly more natural—1-week ones. Alex and others argued this is sometimes because of lengthy release processes: QA taking days, blocking code reviews, and slow CI/CD.
Of course, that’s not the only source of overhead — you have meetings, context switch, and more — but slow releases are a pain for many teams, and they are one of the key items that separate elite teams from good or average ones.
So, what does a good release process look like?
This is one of my favorite topics, so today I am publishing a comprehensive Guide 📖 that puts together everything I know about it, in a framework that you can use at work. It will be a longer article than usual, with plenty of references to past articles to learn more!
I write one of such guides about once a month. You can learn more about Refactoring Guides below 👇
Here is the agenda for today:
🩺 Shipping is your company’s heartbeat — a reminder of why you should ship fast.
🚚 How teams ship fast — there is no single recipe that works for everybody, but there are a handful of things that the many of the best teams have in common.
📊 Metrics for shipping fast — unlike “productivity” and other murky qualities, you can convincingly measure your release process.
🏁 Where to start? — if you are stuck with releases that take two days, how do you actually improve?
💬 Community Stories — more ideas and insights from expert members of the community.
Let’s dive in!