20/80 Rule Reloaded

Table of Contents

The 20/80 Rule Reloaded

A short thought occurred to me.

Many people know and possibly apply the 20/80 rule (the whole Agile framework is based on it!), which, when generalized, goes something like this: “20% of our actions generate 80% of the results.” In other words - “roughly 20% of what we do makes sense.” It’s a strong statement, isn’t it? Simple?

Incredibly difficult! Because we are accustomed and conditioned to fill our time - to have the feeling that we are always doing something.

But that’s not what I wanted to write about. I wanted to point out that many people (I don’t want to use the word “majority,” though I wouldn’t be wrong by much) incorrectly interpret this statement.

It does not mean that once we reach 80%, we shouldn’t put any more energy into further work (project, release, functionality, task, whatever)… in fact, by then it’s too late! We would have already wasted a tremendous amount of our precious time. Because what good is 80% if it’s just crap, a cotton candy of tasks or functionalities?

The above principle means: find the 20% worth focusing on and, once you find it, put 200% energy and commitment into it. The rest can be dismissed, preferably by renegotiating the completion of “the rest.”

Business-wise: instead of creating a large system with 100 features, it is better to ask yourself what will really be useful and what will be used, and create those 20 features.

P.S.

In Domain-Driven Design (DDD), we call it the Core Domain! Always be aware of what your core is! :) Always ask yourself what is the Core in the system, module, or even functionality that you are working on.

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)

Related Posts

The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

By following the steps outlined previously, we begin to see a more structured solution, predominantly consisting of methods grouped into classes. It’s now time to apply object-oriented principles, such as those encapsulated by the SOLID principles. We analyze the code for patterns of repetition, the need for flexibility, and code smells, and introduce design patterns where appropriate.

Read More

Is Poland Christ of Nations?

I recently came across a very interesting article about the pitfalls of the Polish style of management and its historical roots. It is more generic than just IT but includes aspects of participatory management, such as Agile practices. If you understand Polish, you can read the article here.

Read More

Young Manager/Team Leader! Get a Grip!

History tends to repeat itself, and this is a common tale among young managers and team leaders. A recurring, tragic mistake is the commitment to unrealistic deadlines.

Read More