Adding by subtracting

Removing the unnecessary may be your low-hanging fruit for productivity

How often do you hear one of the following?

• What are we missing?

• How could we change our process to prevent errors?

• What could we add to our product?

I hear too many people talking about adding something and barely hear somebody suggesting removing something.

More often than you imagine, subtraction is the best addition.

Here are some questions that helped me increase productivity:

• What do we do that creates little or no value? What would happen if we stopped doing that?

• What could we stop doing today that nobody would miss?

• Which features could we remove that’d go unnoticed?

Adding by subtracting is one of the best ways to increase productivity.

Let me share the ten subtractions that can boost your productivity from today.

#1 Estimate

Do you know why you estimate your backlog items? Did you consciously choose to do it, or did you blindly follow a process?

Many teams I know estimate their work without knowing why.

Most estimates are useless and become a commitment to top management.

Stop estimating.

Great product managers define how much is worth investing into opportunities and evaluate with the team what can be achieved with that investment.

Starting with the end in mind and working backward is often a better choice. You can get to how to get things done instead of abstract discussions.

#2 Old Backlog Items

The longer you keep your Product Backlog, the more costly its maintenance becomes.

I used to put everything into the backlog. Someone would request something, and I’d promptly create a new item. Eventually, we’d have hundreds of outdated items, and I’d need to go through them, talk to people and evaluate whether they’re still relevant. I wasted a lot of time.

Nowadays, I treat backlog items differently. The older they get, the less relevant they become. They age like milk, not wine.

I set the due date to backlog items and delete them whenever that’s reached. I came to realize that three months is a good number. Why should I keep that in mind if the item didn’t make it to a Sprint in three months?

Life is forward, not backward. Use your learnings to define your future, not your old assumptions.

#3 Definitions of Ready

Do you work with the famous DoR? If yes, remove it.

I used to work with DoR. The reason is that I wanted to ensure we had everything under control. Backlog items would follow specific rules. We’d ensure they are refined, estimated, have acceptance criteria, and so on. Only after that could the item make it to a Sprint.

That sounds nice. So, what’s wrong with DoR?

They are an anti-pattern to agile. You create a step to prevent collaboration and discourage teams from exploring the unknown.

For example, if you work with Scrum, your goal is to reach the Sprint Goal and not to deliver all tickets as strictly defined.

DoR forces people to focus on contracts instead of collaboration. Remove that, and your life will be easier. Eventually, you will indeed face a problem with something DoR could have prevented, but that’s fine because you can learn from mistakes instead of avoiding them. That’s about being agile.

#4 Standard Backlog Item

Let me be clear. You don’t have to follow strict backlog item formats. You’re not forced to write them as User Stories.

Although User Stories is the most used way of populating backlogs, it’s not mandatory and is often misused. I wrote extensively about it. Find more about it here.

You can pick whatever format helps the team collaborate. The goal should be to clarify the problem and use that as an invitation to a conversation. From there, you can move.

Don’t force everything as User Stories or whatever other formats. Focus on collaboration instead.

#5 Burndown Chart

Another common misunderstanding is assuming that burndown is mandatory when working with agile frameworks. Don’t take my word on it. Check the Scrum Guide. I will give you a prize if you find the word burndown there.

Many teams believe they have to use burndown to organize their work and ensure they are on track to reach their Sprint Goal. You can use that if you want to, but it’s up to you.

Burndown will force the team to break all backlog items into smaller ones right after the Sprint Planning. This will create a kind of small waterfall inside the Sprint. The team will focus on getting tasks done instead of discussing how best they could reach the Sprint Goal.

Using the burndown will force teams to keep delivering as fast as possible while forgetting that all that matters is reaching the Sprint Goal by the end of the Sprint. It often gets in the way of creativity.

I don’t use burndown charts and benefit from more collaborative and creative teams.

#6 Velocity

I will make this one short.

You should not use velocity unless you want to transform your team into a feature factory.

The moment you introduce velocity, the attention goes to output, and the outcome is ignored. The reality is that features are useless until they can solve real users’ problems.

The goal is to create value and not to ship features at the speed of light.

For the sake of focusing on the right things, please don’t use velocity.

#7 Frequent Meetings

The more recurrent meetings you have, the more mechanic your collaboration becomes.

In remote work times, we tend to set gazillions of meetings, and many are recurrent ones. This is a productivity and creativity killer.

Many teams are energy drainers. Instead of having a set of recurrent meetings, think about what you want to achieve and which would be the best way of doing that. I often realize that a five minutes call with the right person is all I need, or dropping an e-mail with the relevant information can avoid a 30 minutes meeting with ten people.

Reject as many recurrent meetings as possible. Keep to a bare minimum to ensure you have time to act normally and benefit from your creativity.

#8 Approval Processes

No matter what you work with, you will stumble upon approval processes—for example, travel expenses, holiday requests, backlog items, etc.

The question is, why do you need to approve something? Most probably, you do that to guarantee a certain level of quality. But that means someone receives the responsibility of being the quality gatekeeper, while the others may do a sloppy job because someone will check and accept or reject.

I love Netflix’s approach of no rules rules. It’s all about setting the context and trusting people to make decisions.

When a wrong decision is made, correct it by providing feedback and reviewing the context.

Approval processes create bottlenecks and remove accountability from people. For example, approving holidays is unnecessary. You can align with your people the context of taking days off and let them manage it.

Also, approving tickets as a Product Manager is another way of removing responsibility from software engineers. The goal is to point them in the right direction and help them get there instead of focusing on approving their outputs.

#9 Reports nobody cares

Do you create Sprint reports or any other frequent reports? If so, how often do you hear back from those who receive reports?

In my first job as a Product Manager, I used to send bi-weekly reports of our Sprints. I sent the same report for months and never received any answer from stakeholders. Worse than that, I set an output expectation. I wanted everyone to know how we organized our work and the content of the Sprint.

Collaboration is more important than sending e-mails or reports to your audience.

Focus on creating opportunities to exchange and help each other progress instead of pushing reports nobody cares about.

When I realized my reports were useless, I stopped sending them. Unsurprisingly, nobody complained, and I gained that time to do something that mattered most.

# 10 Bad Apple

Do you know the impact of a bad apple on a team?

Let me tell you what happens.

• A low-performer team member will discourage high-performers from giving their best

• Your bar is set by what you tolerate. When you accept a bad apple in your team, that becomes your bar

• Morale goes down as people realize that someone can do poor work and still be part of the team

The longer you keep a bad apple around, the worse the team becomes.

Great product leaders do not tolerate bad apples in the team. They do their best to give feedback and help people evolve, but when that doesn’t work, they will do what’s best for the team.

Final Thoughts

Focus on simplifying instead of complicating. The moment you develop this habit, you can add a lot by subtracting.

In a world where everyone wants to add something, you will be highly rewarded by identifying what you could remove.

“The soul does not grow by addition but by subtraction” - Meister Eckhart