One concept to transform software project management.

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 that make sense business-wise. 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:

needs are challenged to take only what brings value to the customer,
the team works on only one thing at a time,
it finely breaks down this need to quickly present it to the client as soon as a piece is delivered,
it takes the feedback and iterates on it,
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.

The best way to start is to focus on what is the priority.