The 7 wastes of Lean Software Development are: 

• Partially Done Work

• Extra Features

• Relearning

• Task Switching

• Delays

• Handoffs

• Defects

Suppose you are in a leadership role – Agile Coach, Scrum Master, or Manager. In that case, you can work with your team and organization to educate them and help people identify and visualize those wastes. This will result in a list of ideas and suggestions for continuous improvement that is highly relevant to them, increasing the chances of implementing those improvements, and minimizing potential resistance. 

Let’s take a closer look at each of the 7 Lean Software Development wastes in more detail.

Partially Done Work

What is that?

Simply put, it is all the work that is only partially completed. 

Why is this a waste?

If something is not done (no matter the exact definition), it has no immediate value. It is not something you can give to your customers and thus provides no value to your organzition. 

It also means you don’t know if it will work as expected, something you can be sure of when users use or test it.

Unfinished work also contributes to the overall number of items you have in progress. If we don’t keep an eye on how many things are in your development pipeline, it can quickly become overwhelmed. You won’t be able to finish anything and start working on new projects resulting in a downturn in productivity (and that may happen very fast).  

Let me refer to the famous Little’s law – the throughput of you or your team depends on how much work you have in progress and how much it takes to finish each one of the items. The more you start, the more you don’t complete – the more productivity will suffer.

Some examples

Think of anything almost done – in software development that might be code in a local branch and not integrated into the central repository. In that case, it is functionality that’s not fully tested.  Similar to requirements that are thoroughly detailed and completed in advance but are not implemented.

How to minimize it?

Some ideas on how you might reduce and minimize partially done work:

Clarify what done means.

Whether Definition of Done if you use Scrum or concrete and explicit policies if you use Kanban,  there should be a clear understanding of what counts as finished and what doesn’t. Without that, people may lack clarity about the expected result, and everyone may have a different interpretation. This may be not only a source of wasteful activities but also disagreements and potential conflicts.

Focus on finishing work. 

Stop starting new things before finishing what you are currently working on. It can be that simple, and implementing this kind of discipline will soon pay off. If you face external pressure – educate your stakeholders and don’t hesitate to seek support.

Don’t demonstrate unfinished items on Sprint Reviews (if you do so). 

This practice promotes partial completion because you demonstrate unfinished work. Besides, you may confuse and mislead the stakeholders if you do this as they may think something is finished since they saw a demo.

Set some limits on ongoing work 

You may start with a very pragmatic agreement, like working on one thing at a time and avoiding multitasking. Once you have the continuous flow of completed work, you can experiment and further optimize the limits. We will discuss this in more depth in the section for addressing Task Switching waste.

Extra Features

What is that?

Features that are not requested or needed by your existing or potential customers. 

Many think this is a rare situation; unfortunately, that’s not the case. According to the Standish Group report for 2018, half of the features created are hardly ever used (read an article here).

Why is this a waste?

Developing unused features is the ultimate form of waste. Even if you have the perfect development process and have delivered a high-quality feature, you spent resources developing something no one will use.

“BUILDING SOMETHING NOBODY WANTS IS THE ULTIMATE FORM OF WASTE.”

ERIC RIES

Not just that, but these unneeded features contribute to the system’s overall complexity requiring someone to document, maintain, support them. Not to mention any potential changes in architecture needed to bring them to life.

Some examples

A good source of insight is analyzing your existing product and identifying the usage of various features. Another source can be looking at current requirements and asking how the features being developed will bring value.

How to minimize it?

Know your market, customers, and users.

Invest in understanding your market, customers, users, and their needs! Understand their problems and potential opportunities before jumping into possible solutions will be invaluable. I am a big fan of using Design Thinking so expect more on this topic in the future.

Validate ideas early and often

Use iterative and incremental approach and validate different coded and non-coded assets along the whole software development lifecycle. 

This will give you the chance to start learning before investing a lot in feature development. You can test business models, mockups, prototypes, conduct focus groups to identify features your customers will want and use. I will write a dedicated article on this topic in the near future.

You can often also release functionality iteratively and incrementally and adapt your plans based on customer feedback and/or specific metrics you observe. For example, if you release functionality that you expect to grow your product’s daily active users, monitor it closely to see if that happens or not.

Check your opinion

Try to base your decisions on research and validated learnings. Your opinion of what is supposed to be valuable can guide you but should not be the only source of insights. It is best not to make decisions in a vacuum; seek input and validate your decisions before implementing them. Implementing something just because you think it’s cool is not always a good idea.

Ask yourself – What makes us believe that what we are doing will bring value to our customers and users?

Stay tuned for part 2