Should you use Scrum in 2024? 🗺️
A first-principles approach to dev process frameworks, plus a ton of real-world stories from the community.
Last month I started doing weekly interviews for the podcast. I have done four already, and one of the topics that comes up the most frequently is development process.
In the recent chat with Aadil Maan, we discussed how the best teams often take pieces from canonical frameworks like Scrum or Kanban, and mix&match them to fit their needs.
Is this how you should think about them? Or is it good, sometimes, to just trust the framework and slap it onto your team?
The answer is less trivial than it seems.
Two years ago I wrote a full piece about Scrum. I have used Scrum for many years — at first, almost religiously, then less and less so, until we could hardly call it Scrum anymore.
Later, since I started Refactoring, I have had the chance to talk with countless managers and CTOs about their dev process and how it evolved over time.
So, today we will try to connect the dots, and write an updated take on Scrum and, more in general, how to use frameworks for good.
Here is the agenda:
🔄 The Role of Processes — what we should expect from them.
⚖️ Criticism to Scrum — why people complain about Scrum.
🔨 The meta-dev cycle — a first-principles approach to what the dev cycle should do.
🎽 Team Maturity — how your team stage impacts what the best process looks like.
📱 Product Maturity — how your process should evolve alongside your product.
💬 Community Examples — five stories and processes from real-world companies
📌 Bottom Line — parting advice to summarize what we covered.
Let’s dive in!
🔄 The Role of Processes
A process is a repetitive series of actions you take in order to achieve a particular outcome.
In the context of an engineering team, the dev process enforces a way of working on code and product that guarantees some quality.
What quality, though?
As Cate Huston wrote, processes can only guarantee adequacy, rather than excellence. By definition, they are a mechanism of standardization — so their domain is that of reliability, rather than greatness.
And that’s ok. True greatness comes from people. As Will Larson points out:
With the right people, any process works, and with the wrong people, no process works.
So, the best processes get two things right:
Enforce the basics — to guarantee adequacy and relieve people from decision fatigue.
Stay out of the way — to let people shine and create greatness.
How does Scrum fare on this?
⚖️ Criticism to Scrum
Scrum gets a lot of flak for many things these days. You can organize this criticism along two axes:
Overhead — Teams complaining that it has too many ceremonies / it is too prescriptive.
Sprint duration — Teams complaining that one or two weeks are not enough to deliver meaningful product features.
These angles are not orthogonal. For many teams, Scrum ceremonies are correct, but they become too much because they all happen on a single Sprint cycle. So you see all kinds of hybrids: fewer ceremonies + same short cycle, or same ceremonies + longer cycle.
This is not specific to Scrum anymore: you can catalog pretty much all dev process frameworks based on 1) which ceremonies they include, and 2) how frequently you have them.
Differences can be radical. A normal Scrum process has Sprints that last either one or two weeks. Shape Up by Basecamp, instead, works on 6-week cycles.
Are these even the same jobs?
To understand why such differences exist, let’s take a step back and look at what you do on a cycle, at a meta level 👇