Waste – How the 7 wastes of Lean apply to software development

Waste. It’s always bad, and particularly in business, and even more so in project management. A great deal of project management is geared towards avoiding waste, and this is where ‘Lean’ processes come in.

seven wastes of LEANThe seven wastes of lean are well known, but on paper they appear to apply to manufacturing processes. With a little helpful translation, however, they adapt beautifully to the process of software development, and can be a very useful framework from which to examine the project management of software development, as outlined below:

1)    ‘In-process inventory’ translates to ‘Partially done work’

This is often seen as the most damaging of all wastes, which can de-rail any software project quickly. It includes finished, but un-checked code, undocumented code, untested code, code which is not yet in production, and code which is commented out.

2)    ‘Over-Production’ – translates to ‘Extra Features’

It is a broadly accepted statistic that almost two thirds of the functionality and features in any software application are rarely (or never) used. When you think about this, it means that two thirds of the effort put into building and maintaining software is largely a wasted effort. There are both direct and in-direct wastes here also – the time taken to build the unused software features is a direct waste, but the indirect waste is the maintenance of that code and functionality over time, into the future.

3)    ‘Extra Processing’ translates to ‘Re-learning’

Continuous learning, or the avoidance of re-learning the same information, is one of the key facets of good project management methodology. Re-learning is particularly wasteful in a software development environment. Failing to learn from mistakes is uniformly costly, and somewhat unforgivable.  Within software development, this includes poor quality and weak planning, switching tasks, bad communications within and without the software development team, and the dangers of undocumented code.

4)    ‘Transportation’ translates to ‘Handoffs’

Instead of the transportation of physical material, in software development this waste is virtual, but equally important to avoid. It can include the transfer of code from one developer to another, the handoff of software from developer to tester, and the movement from development to deployment. Strong, documented communications between all of the above are critical to avoid serious waste in time and resources.

5)    ‘Motion’ translates to ‘Task Switching’

This is where a software development team member transfers from one specific task to another, without completing the first one, thereby interrupting the on-going flow. It also applies to a shared team is working on more than one project at a time, and often occurs when there is a lack of proper coordination between the product owner and the development team.

6)    ‘Waiting’ translates to ‘Delays’

This refers to anything which delays time in the delivery of a component of the software in question. This could be anything from a lack of capable resources, a myriad of items in-progress, external and uncontrollable dependencies, a lack of understanding of what really adds ‘value’, or any number of unwanted and unnecessary processes that should be called out.

7)    ‘Over-Production’ translates to ‘Defects’

In manufacturing, over-production can be a safety net from faulty or unreliable manufacturing processes. In software development, this can be distilled down to software defects. These can have a broad range of causes, but all can be avoided. Defects often arise from a lack of understanding of the story, a lack of efficient engineering processes, missing acceptance criteria, a lack of technical skill among team members, or the late involvement of testers in the process, with inattention to automated testing.