Those who understand this concept will own 100% of the software development market share by 2030.
It's about the principle of resource efficiency vs flow efficiency in Lean.
Let’s take a simple example: a machine processing a product operates 100% of the time. Its “resource efficiency” is thus maximized. The problem is that due to poor calibration, it continuously reworks the same product. So, it operates 100% of the time, but because of these “restarts”, its delivery time is infinite. Its “flow efficiency” is therefore zero. ❌
It seems obvious, but if I rephrase the sentence as “it’s not because your developers are working 100% of the time that they are productive,” then I will attract the wrath of velocity and bullshit metrics fanatics. 💩
Let me explain: In the world of software, value mainly comes from the delivery of new features. The problem is that for many reasons, sometimes good, sometimes bad, the delivery time is long.
This creates a whole range of so-called “secondary” needs:
- Task tracking to know who is working on what
- Estimation of each task to try to gauge the project’s progress
- Backlog organization work: labeling, prioritizing, epics…
- Meetings for communication, information dissemination
- Etc…
To meet these needs, we need to add roles in a team, create new processes (estimation sessions, “““agile””” ceremonies, etc…)
Inevitably, it’s recursive: these new processes lead to even more organizational needs, which can lead to others. 🤯
And that’s how we end up with organizations where people work hard, at 100% and sometimes even more, and deliver very little…
The worst part is that we might even think that our work makes sense while we’re addressing a secondary need! “After all, this backlog needed to be organized!”
This has a cost. In time, money, and brain juice.
👉 Now, let’s consider the situation where:
1️⃣ needs are challenged to take only what brings value to the customer,
2️⃣ the team works on only one thing at a time,
3️⃣ it finely breaks down this need to quickly present it to the client as soon as a piece is delivered,
4️⃣ it takes the feedback and iterates on it,
5️⃣ and once the need is met, it moves on to the next most important one.
No need for complex backlog management, no need for estimation mechanisms, grooming, and whatnot, no need for “sprints”.
When we focus on flow efficiency, a significant number of secondary needs disappear. This is what Lean calls waste: the scraps. By focusing on flow, we eliminate this waste.