7 Lean wastes that you need to avoid at all cost

We need to avoid them at all cost if we want to become more productive.

We often think that we waste our time because of small things. Like getting a coffee or having a bigger lunch. But the reality is that the work we do is filled with time wasters that cost us more time than any break that we take.

If we are not able to identify and mitigate them, we are doomed to never get rid of them.

The initial 7 lean waste came from the Toyota Production System, and were applied to lean manufacturing. In a sentence, to factories. But over the years it has evolved. It evolved in a way that we were able to map them to our industry of software development.

This is a summary of the 7 lean wastes.


#1 Task-Switching

Man Connection Utp Cables on Switch Hub Inside Room

We waste time when task or context switching because of something called the psychological refractory period.

Without entering into much science, it means that whenever we need to stop what we are doing and move to something else, our brain needs to adapt. That adaptation is not free, it takes processing power and that in the end is time. It can cost you up to 40% when task-switching.

And if you are thinking. NO, I can multitask without wasting time. Then, my friend, you are a lucky one and part of a very exclusive group. Only 2% of the population is good at that, so, congrats.

Read the full article here

#2 Partially Done Work

Newly Make High Rise Building

Yesterday I was having a chat with one of my teammates and he mentioned the analogy I used for this one. I think it is the best way to explain partially done work.

One person is peeling an apple with a knife, and another person is peeling a potato with a potato peeler. Who is the fastest?

You may say the potato person is the faster right? He/she has the right tool. And we all know that if we use the right tool for the job we become more productive.

But the devil is in the details. The outcome in both cases is very different. One gives you an edible product that you can use right away, the other will still need extra steps to be completed, like seasoning and cooking. Unless you like raw potatoes, then this is completely different.

If you think about it, when you leave partially done work on the table, you are also task switching. One waste feeds into the other.

Read the full article here

#3 Delays

Person Wearing Round White Analog Watch at 10:09

Why do we leave partially done work on the table? Most of the time, not all of the time, but most of the time this is due to delays. If you need to start tackling any waste, I would suggest going for this one first. Why? Because it bleeds into two of the other lean wastes.

Delays cause work to be unfinished (partially done work), so we need to move our focus to something else (task-switching). This is why communication is important, proper planning so that we don’t get held up with delays.

Plans are nothing; planning is everything.

 Dwight D. Eisenhower

As President Eisenhower said, planning is important, but don’t get held up on the plan either. We need to malleable. We need to have the agility to adapt to what comes ahead.

If you want to fix one and only one of the lean wastes, as I said before, try and fix this one.

Read the full article here

4# Hand-Offs

Pile of Folders

I love this quote.

Code is like a good joke, if you have to explain it, you are doing it wrong.

Ok, I understand it is not as simple as that, but it makes a point. If your code does not speak for itself, then we need to do a hand-off, right? And hand-offs take time. They need to be documented (extra work). Meetings need to be setup (task-switching).

Another quote that I love is:

The best communication is no communication

If what you have is so clear that you don’t need to explain it, then there is no need to hand-off. We can save time by making everything visible that can be visible.

And remember, hand-offs only work, because we assume no information will be lost during the hand-off. If you ask me, this is a real risk assumption.

Read the full article here

#5 Extra Work

Person in Blue Shirt Wearing Brown Beanie Writing on White Dry Erase Board

If you do waterfall software development, there is a high chance you are doing extra work. Why? In one word, Feedback loop.

Extra work occurs when you don’t know that you did everything that needed to be done. As simple as that.

80% of the value comes from 20% of the features

We all know this. Just look at the options bar on Microsoft Word. How many of those features do you use? Now think about how many other pieces of software you have that contain features that you never use. If most people don’t use it, why did we spend time building it?

Well, the answer is simple. Delays in the feedback loop. We kept on doing things without asking “If we deliver now, do you have everything you need? Or do you want to spend more of your money developing these extra things?”

Read the full article here

#6 Defects

Black Claw Hammer on Brown Wooden Plank

Oh, the dreaded defects. Bugs. Incidents. Status pages and on-call support.

One thing we can all agree on, and if we cannot, we should, is that bugs are part of any software. So why are they a problem? Simple, they cost time to fix. Not just the time to fix, but also the time they were in production messing something else without being found.

We can never get rid of all the bugs, but that doesn’t mean we should not try and mitigate them. There are several ways we can do this.

We need to have automated testing and continuous delivery to prevent errors that we already know. We should have on-call support, triage phase, and an internal service desk to deal with new bugs that escape our process.

Just because we cannot live without them, doesn’t mean we need to accept them. Especially if we have already dealt with them. Which segways right into the last lean waste.

Read the full article here

#7 Relearning

Person Behind Books

Nothing is more frustrating than having to learn what you already learned before. Imagine that today you completely forget the ABC and have to learn it all over again. How long do you think it will take you?

In reality, it doesn’t matter how long, it is already a waste. Why did you forget it in the first place? This is the real question that causes re-learning.

How much did civilization lose, when the great library of Alexandria burned to the ground?

Usually, there are deeper underlying causes than just forgetting. For example, hand-offs. There is a high chance something will be lost in translation. Information lost is information that needs to be gathered again, meaning, re-learned.

Those who do not learn history are doomed to repeat it

The agile manifesto puts a good emphasis on “working software over comprehensive documentation” and I couldn’t agree more. Pay close attention, it says over, not instead. Proper documentation will save you time if you ever have to re-learn something.

Read the full article here

Cheers,



Join this newsletter to get exclusive content.

Relearning might look like a good thing, but it’s not

If learning is good, why is re-learning a waste?

How much did civilization lose, when the great library of Alexandria burned to the ground?

👇 (This is the same intro for all the lean waste posts. If you have read it already, scroll down for 4 paragraphs) 👇

We waste time all the time. Small unimportant tasks. Procrastination. Looking at nothing (this one is not really a time waster if it clears your head). The world is filled with traps that make us waste our time, and some of them we already know how to detect and adapt to them.

Photo by Stas Knop from Pexels

Lean Manufacturing talks about the 7 lean wastes, these wastes can also be mapped to software development.
During these next 7 days, I will pick up one of the wastes and investigate the following questions

  • Why does it impact our work?
  • What could be the causes of this?
  • How can we measure it?
  • How can we avoid it?

For today, the focus is re-learning. If learning is good, why is re-learning a waste?

How much did civilization lose, when the great library of Alexandria burned to the ground?

Learning how to do something is the most rewarding experience one can have. But if we learn and then forget, what value is in this learning?
The same goes for software projects. If the code we do is so complicated that the next time we look at it we don’t understand, that is a very big waste of time.

Information that is lost in translation, lack of comments or documentation, is information that we will need to re-learn later in the future. Re-learning is usually fueled by other gateway drugs of time waste. Hand-offs, delays, and task-switching are the major causes of having to re-learn what we already did.


Why does it impact our work?

Photo by Pixabay from Pexels
  • We don’t learn new things and keep re-learning that same thing over and over.
  • If we don’t remember, we are doomed to commit the same mistakes.

What could be the causes of this?

Photo by Pixabay from Pexels

How can we measure it?

Photo by Lukas from Pexels
  • # time to repair. If your bugs are similar, the time to repair should be reduced over time
  • # similar bugs. If we keep committing the same mistakes.
  • Code standards, smells and linting.

How can we avoid it?

Photo by Linda Eller-Shein from Pexels
  • Code should be properly documented and reviewed by your peers
  • Refactor constantly to keep the code fresh
  • Automate everything that can be automated, that way you don’t need to remember
  • Continuous improvement – Kaizen
  • Pair programming and knowledge sharing

Cheers,



Join this newsletter to get exclusive content.

These are the 3 ways bugs are destroying your output

Bugs are part of life and part of any code, but they cost time to resolve. They cause extra work on the part of the development team, usually at bad times, causing unnecessary stress.

👇 (This is the same intro for all the lean waste posts. If you have read it already, scroll down for 4 paragraphs) 👇

We waste time all the time. Small unimportant tasks. Procrastination. Looking at nothing (this one is not really a time waster if it clears your head). The world is filled with traps that make us waste our time, and some of them we already know how to detect and adapt to them.

Photo by Stas Knop from Pexels

Lean Manufacturing talks about the 7 lean wastes, these wastes can also be mapped to software development.
During these next 7 days, I will pick up one of the wastes and investigate the following questions

  • Why does it impact our work?
  • What could be the causes of this?
  • How can we measure it?
  • How can we avoid it?

For today, the focus is on Defects. Bugs are part of life and part of any code, but they cost time to resolve. They cause extra work on the part of the development team, usually at bad times, causing unnecessary stress.

Left to themselves, things tend to go from bad to worse

Murphy’s Law

Although some bugs are part of life and we cannot run from them, others are just a symptom of a bigger problem. Not only do we have to spend time fixing and testing the code that will resolve the bug, the main issue is also all the time the bug has been undetected.
When we finally find it, there is a high chance more bugs will come from that one.

Anything you try to fix will take longer and cost you more than you thought.

Murphy’s Law

Why does it impact our work?

Photo by Pixabay from Pexels
  • Task-switching and Partially Done work, we need to move from our development work to solve a bug.
  • Blocker on production affecting a large number of customers becomes “all hands on deck”, stopping all other work immediately.
  • Minor defects get de-prioritized and then come back in the future to bite us.

What could be the causes of this?

Photo by Pixabay from Pexels
  • Extremely tight deadlines that force the team to hack the code together.
  • None or a small amount of test coverage.
  • No automated tests.
  • Manual steps in the deployment process.

How can we measure it?

Photo by Lukas from Pexels
  • Time to Repair, how long on average do bugs take to resolve
  • Number of Bugs created vs resolved per week

How can we avoid it?

Photo by Linda Eller-Shein from Pexels
  • Automated and high test coverage
  • Continuous integration and deployment
  • No manual steps after the code has been validated

A 100% bug-free code is a myth. Defects will always happen, the only thing we can do is to mitigate the risk, but never eliminate it completely.

Every solution breeds new problems.

Murphy’s Law

Cheers,



Join this newsletter to get exclusive content.

Why you need to stop obsessing about working hours

It feels a bit strange that in 2019 we are still talking about working hours and how different they are from hours worked

It feels a bit strange that in 2019 we are still talking about working hours and how different they are from hours worked. How many hours someone spends in the office. How many coffee or cigarettes breaks they take (Don’t do cigarettes. It’s bad for your health). Or worse, how much time they spend chatting next to the water cooler, or coffee machine.

Working SMART instead of working HARD

During the height of the industrial revolution, having a factory job was the thing. We would probably be working as part of an assembly line. Each one of us would be specialized in doing the same repetitive task over and over. The longer we were there, the more we would produce.

Photo by ELEVATE from Pexels

A long time ago we tried to do something similar in I.T. We estimated our projects in man/hours. We used to estimate the output in lines of code. Heck, we even created the role of Line Manager to help all of this go smoothly. Does this role sound familiar? That is because the Line Manager comes from Assembly Line Manager. We were always bad at coming up with names.

I.T. work is a creative one. Algorithms are not created by spending hours in front of the computer, they are created in your head. Problems are not solved by injecting new lines of code, they are solved by thinking, and sometimes, to properly think, you need to move away from your desk. Move to a new place to stimulate the brain, and then work on the problem.

Photo by Pixabay from Pexels

Luckily, for some of us at least, over time, we came to realize that outcome is different from output. We understand now that having fewer lines of code is better than more. Why? because it is easier to maintain, review and test.

Hours spent on site are not a synonym for good work. Most of the time the relationship is the complete opposite. If you have a colleague always sitting at their desk without a break, there may be 2 underlying problems and you should try and help him/her.

  • He/she is not good enough (yet) to perform the task in that time-frame. This means you should seek to train or mentor their technical skills.
  • He/she has really bad time-management. This one is harder but it can also be trained.

High performers will be able to work without looking at a computer. Their mind is always debugging and creating new algorithms. They try and find inspiration outside of their own box. Talking with a colleague over coffee. Going outside to look at the street. The most important part of the work happens in the head, not on the keyboard.


It is not rocket science to be a good manager. The job is not to control what your team does. How many breaks they will take. Or at what time they arrive at the office (especially if you don’t know what time they will leave).
Instead maybe bring coffee to the team. Create a good working environment, not a hostile one, and you will see how much more your team will produce.

Lead the way and bring them with you on this journey. Pull them in, don’t push them out.

Photo by Miguel Á. Padriñán from Pexels

You can disagree with me, and that is fair. You can do the complete opposite. But remember, in the end, they are the ones creating the value, not you. If they are not happy, they will find another place. And in today’s market, that’s not a hard task.

Cheers,



Join this newsletter to get exclusive content.

The most important metric you need to track

For today, the focus is Delays. This is the most important metric you should be tracking because it impacts everything else.

👇 (This is the same intro for all the lean waste posts. If you have read it already, scroll down for 4 paragraphs) 👇

We waste time all the time. Small unimportant tasks. Procrastination. Looking at nothing (this one is not really a time waster if it clears your head). The world is filled with traps that make us waste our time, and some of them we already know how to detect and adapt to them.

Photo by Stas Knop from Pexels

Lean Manufacturing talks about the 7 lean wastes, these wastes can also be mapped to software development.
During these next 7 days, I will pick up one of the wastes and investigate the following questions

  • Why does it impact our work?
  • What could be the causes of this?
  • How can we measure it?
  • How can we avoid it?

For today, the focus is Delays. This is the most important metric you should be tracking because it impacts everything else.

Delays, or waiting time, impact all the other lean wastes. For example:
If you have to wait, you will pick something else to do. This causes context/task-switching.
On the other hand, what blocked you is still not done. This causes partially done work.
If by any chance your work is done, but you are waiting for feedback, there is a high chance you will pick another part of that project. This can cause extra work that the customer won’t need. But we don’t know because we don’t have the feedback yet.

Photo by Pixabay from Pexels

It is like one thing fuels the other and enters a never-ending spiral of wasted time.

Why does it impact our work?

Photo by Pixabay from Pexels

What could be the causes of this?

Photo by Pixabay from Pexels

How can we measure it?

Photo by Lukas from Pexels
  • Age of the backlog. Old tasks that are there waiting for a long time.
  • The amount of time an item is flagged.
  • Gates in the process. I.E time waiting for UAT, waiting for release approval.
  • Gap between development ended and test starting.
  • Gap between work DONE and releasing it to production.

How can we avoid it?

Photo by Linda Eller-Shein from Pexels

Cheers,



Join this newsletter to get exclusive content.

How to do less work and skyrocket your productivity

This is a clear case of effectiveness vs efficiency. We have the best code ever. 100% test coverage. A dream pipeline that delivers everything to production without a single bug. If no one is going to use it after, we just wasted our time.

👇 (this is the same intro as yesterday’s post if you have read it already, scroll down 4 paragraphs) 👇

We waste time all the time. Small unimportant tasks. Procrastination. Looking at nothing (this one is not really a time waster if it clears your head).
The world is filled with traps that make us waste our time, and some of them we already know how to detect and adapt to them.

Lean Manufacturing talks about the 7 lean wastes, these wastes can also be mapped to software development.
During these next 7 days, I will pick up one of the wastes and investigate the following questions

  • Why does it impact our work?
  • What could be the causes of this?
  • How can we measure it?
  • How can we avoid it?

For today the focus is Extra Work. Extra work means everything that we did that didn’t need to be done.

80% of the value comes from 20% of the features

This is a clear case of effectiveness vs efficiency. We have the best code ever. 100% test coverage. A dream pipeline that delivers everything to production without a single bug. If no one is going to use it after, we just wasted our time.

It may look counter-intuitive to consider a waste if you are producing more, but the output is not the same as the outcome. Producing more of something that will not be used has 0 value. Heck, in this case, it even has a negative value because you could be spending your time with something else.

Imagine you have the best hot dog stand in the world, but you are parked in an area of vegetarian and vegan customers. It doesn’t matter how good your hot dogs are, no one will buy them.

Why does it impact our work?

  • If it’s not going to be used, why do it?
  • We will need to maintain them.
  • If they break, they may break something else that is being used.
  • Our team spent time testing, reviewing and deploying it for nothing.
  • Increase our code complexity.

What could be the causes of this?

  • We don’t know our customers and his/her needs.
  • We don’t validate value propositions.
  • We don’t have customer metrics that allow us to understand what is being used or not.

How can we measure it?

  • #features in production that are used by the customer
  • #items delivered that are focused on the MVP

How can we avoid it?

  • Break features as small as possible and review them with your stakeholders.
  • Release to production often and gather usage metrics.
  • Proper prioritization of the backlog and focus on MVP by using the Eisenhower matrix.

Cheers,



Join this newsletter to get exclusive content.

How to unlock the value of a definition of ready

This is an on-going battle for the agile community. Should we have or not a definition of ready?

🥊 This is an on-going battle for the agile community. Should we have or not a definition of ready?
I believe that there is a lot of value in having a definition of Ready. Saying this, we need to be very careful about how we use it.

Like anything in the world, with great power comes great responsibility. Thanks Uncle Ben 👍

What is the definition of ready?

The definition of ready is a checklist that helps the product owner/product manager write better tickets. Simple, right?

This checklist of requirements is an agreement between the team and Product Owner / Product Manager, of the must-haves pre-requirements in every item. This agreement allows the team to push back if something does not meet the standards, and also allows the PO/PM to know what is needed by the team.

So how can we unlock the value of a DoR and not step into a couple of pitfalls?

First and foremost…

Why should we have one?

Although the definition of ready is an artifact for the team, the one that will use it the most is the Product Owner.

For each and every ticket to be refined by the team there is always a set of requirements that need to be met. These already known requirements should be transparent to all and listed to make the PO/PM life easier.

Sometimes we forget that a PO/PM is also human. This person also has deadlines and stress, and there is a very high chance that, like any other human, that sometimes he/she may forget things.
If you have a checklist for him/her to follow before coming to the team with a ticket it is a win/win.

In a sense, the DoR prevents unnecessary discussion when we all know what is necessary. It prevents time loss. Back and forward. And most importantly, it avoids frustration.

  • “You always bring us the tickets without this and that …” – add it to the DoR
  • “Why don’t our tickets always have acceptance criteria written down?” – add it to the DoR

It looks like a couple of good reasons, right? So where are the pitfalls?

Why shouldn’t we have one?

There are a couple of reasons why you shouldn’t have or use a definition of ready, and that mainly depends on the level of collaboration you have.

The DoR is a gate for development.

Welcome back to the old days of Waterfall software development. If your goal is to put gates, then just don’t use it.

Be very careful with the items in your DoR to make sure you are not putting “Following a plan” before “Responding to change”.

The DoR is to force the PO/PM to go back and get all the items.

Although you may say this is the job of the PO/PM, in the end, he/she is part of your team. All team members should collaborate together to get this checklist done.

There will be times when some items in the DoR are valuable but cannot be solely resolved by the PO/PM. In this case, the development team should help.

Remember, we should all be rowing the same boat.

The DoR is a contract that will never change

Similar to the DoD, the DoR is a living document. Checklists are only as good as the items in them.

If something no longer makes sense, take it out of the DoR.
If something new is found, add it to the DoR.

Keep the document updated and you will have a better collaboration.


Whatever you decide to do, have a DoR or not have a DoR, in the end, make sure you have a good collaboration with your full team.
For me, the most important agile value is “Individuals and Interactions over Processes and Tools”.

Cheers,



Join this newsletter to get exclusive content.