The Fundamentals of Planning: A Graph About Scoping And Prioritization

Andreja Dulović — Tue, 25 Aug 2020 13:48:17 +0000

Here it is:

This is a form of the famous Pareto rule: roughly 80% of the effects (“Usefulness”) come from 20% of the causes (“Efforts”).

But this article is not about the Pareto principle; it is about the development of software systems and technology. Specifically:

Why most people will verbally agree on what is essential but still fail to think (and act) accordingly
What to do about it
Exceptions — when is perfectionism necessary

Why do we waste time and effort on less important things?

It can be difficult to accept that we are going to build something imperfect.

“We want to make the best product! Improvements are easy to spot, so why don’t include them!? Let’s build a future-proof system, optimize and automate everything! Let’s add more things to cover more use cases!”

Thinking like this often ends up in failure, disappointment and late releases.

I am trying to figure out why do we think like this. It is easy to propose a gazillion methodologies to “solve” this issue (Scrum works to address it, but it fails if not implemented correctly). Solution always depends on the context. I would instead like to understand why we lose the focus on essential things.

1. Education

Maybe because in school, we got our grades (acknowledgement and sense of achievement) based on how close to perfection we did on the exams? The famous saying “you get what you measure” applies here — good students chase perfect grades.

I recommend the book “Surely You’re Joking, Mr. Feynman!”. If you don’t have the time to read it (which would be a pity), here is a short excerpt that shows how people focus on less important things in education.

Organizations have scoring systems that indicate who can do bad/good/best work. Because there are no grades, we are looking for things under our control which we can make “perfect”, hoping that they will show our value and contribution. We disregard the usefulness (impact on revenue, for example).

Fear of being perceived as an underachiever makes us chase perfection even though it may not be relevant. We fix our efforts on something that we believe we can successfully do, instead of something beneficial we should do. We can waste a lot of time like this.

Besides, we don’t always know what is essential for the business at the moment, so we miss the target.

2. Who had set the bar and based on what?

Another reason for chasing perfection (sub-optimal value) may be measuring our work against the most famous in our domain. Someone set the bar in your community, and many are copying them.

Everyone knows and admires Ferrari. They make cars on the right part of the graph, close to perfection. You can downplay and ridicule (almost) any car by comparing it to a Ferrari.

Fiat Panda looks stupid compared to it. Look.

But nobody talks about the fact that FIAT bought Ferrari (90% ownership in 1988) and that their revenue is ~30 times bigger. FIAT produces mostly ordinary, dull cars that fulfill 99.9% of all the daily needs for transport — and it’s a giant company. It’s an excellent example of how the graph works. FIAT excels on the left part of the graph, and they make much more money than Ferrari.

It is similar in software engineering. Each era has a set of modern technologies. They become favoured by people telling success stories, and these days, via aggressive marketing. Decades ago it was COBOL, for example. Today it’s the Kubernetes, serverless, event sourcing, etc.

Following trends without an exact plan on how will it bring benefit to your business doesn’t sound right.

What to do about this?

Promote a different definition of perfection.

Achieving perfection in technology is impossible because requirements continuously change. Everything we ever develop will one day be deleted and will reach the end of the life cycle.

I think we need to redefine “perfection” like this:

Perfection is an optimal ratio of usefulness and effort to release the product (increment)

Optimal means: a measure of contribution to the business vs time and resources needed to deliver it. (Still sounds complicated, can we simplify? Any ideas?)

There are methods to measure the value/contribution, but let’s not go there. The best technique depends on the context, teams and business, and this article is already long.

The goal is that your teams reach a level of maturity when they don’t need a process or a person who decides what is optimal. The teams can autonomously make better decisions if they go for a different kind of perfection.

It is so much easier if managers support “the graph”.

One simple thing that anyone can do is, for example, ask: “How will this benefit our revenue in the next month or two?”. And then leave it. Don’t push. The goal is to kick-start the mindset, water it until it becomes the standard.

Exceptions

There are situations where anything less than perfection equals disaster. Some examples include flight control, brain surgery, the up-time of the stock exchange systems. These are the high-risk areas where releasing imperfect products makes no sense.

Why Is Retrospective Difficult And How to Learn From the Past

Andreja Dulović — Wed, 12 Aug 2020 08:41:51 +0000

“Memory never recaptures reality. Memory reconstructs. All reconstructions change the original” — Frank Herbert

Engineering requires regular diagnostics, retrospectives, postmortems, root cause analysis, etc. We want to reflect on the past and learn something from it.

But often this doesn’t work. Some teams identify causes and still struggle with the same issues over and over again. Some people “never learn”. It seems like we don’t always learn even from the best descriptions and analysis of past events.

Many times I have seen fantastic root cause analysis, and as soon as the next day, the people reverted to the usual, almost instinctive behaviour. Everything was identified, but nothing changed.

Why is this so?

We don’t like ambiguity, so we make stories with “logical” conclusions. It gives a sense of safety. I love the term the author used: “delusional clarity”.

When doing a retro, there is no way to know for sure if we took everything that happened into account (unknown unknowns). We may even have a preference where we wish a root cause to be (a specific person, team or a system) — and tailor our story to fit that. A mix of facts and assumptions is tough to “debug”.

Sure, some people are a bit more objective than the others, but let’s be honest; objectivity sometimes doesn’t mix well with talk about what went wrong and why (depending on the team).

What to do about this and how to learn from mistakes?

Describing a chain of events is good to kick start a discussion. And that is all it’s suitable for.

The most valuable learning is to find out what was (and what was not) in our minds during the time of the error.

Ask this:

Why did it look reasonable for us to do this the way we did?
Why the important things were not important to us before the error and at the time of error?

Next-level retros

Do a retro when everything went well. Ask questions like “What could have happened that would have made us fail? What can we optimize even more? What should change in the future so that our solution will require a change? How will we detect a need for change?”

DEV Community: Andreja Dulović