Should you use Scrum in 2024? 🗺️
A first-principles approach to dev process frameworks, plus a ton of real-world stories from the community.
This year I started doing almost weekly interviews for the podcast. I have done 30 so far, and one of the topics that comes up the most frequently is development process.
In my 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 the newsletter, and especially the community, 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 👇
🔨 The meta-dev cycle
A first question you may have is: should I work in cycles at all? After all, there exist frameworks—e.g. Kanban—which are more about continuous work.
For product development, my answer is an easy yes.
The main virtue of cycles is that they enable feedback loops — with customers, stakeholders, between developers, everyone. Feedback loops enable improvement and make sure you keep doing the right things.
Product work is 1) inherently uncertain, and 2) involves many different stakeholders, which makes feedback crucial.
Cycles and ceremonies are also important for managers to have reliable spots in which to take action. Without them, you would either end up 1) not working enough on problems, or 2) being on the alert all the time.
So what do you do on a cycle? At a team level, ceremonies revolve around three things:
🗺️ Planning — deciding what to do next.
🔀 Coordination — removing obstacles and avoiding being stuck.
🗳️ Feedback — discussing how you are doing and how to get better.
This is of course, meta work — the actual work is writing code, creating requirements, releasing, etc. — but still, it’s legit work. Every team needs to do these things in a way or another, whatever framework they choose.
So here is what Scrum does about them: