A large part of the success of the lean manufacturing movement was its call to eliminate waste. Deming introduced the concept that waste in manufacturing came from excessive inventory. Inventory was considered waste because it tied up capital and required that it be kept in storage until it was ultimately sold.
But what is waste in software? Unlike physical goods, software has no mass so it doesn’t need to take up space, and it doesn’t wear out. So do lean manufacturing concepts really apply to the software construction process?
In software, waste is defined as any work that has begun but is not yet completed. We define work in progress as waste for two main reasons. First, like inventory, work in progress is unused while under development, and therefore no value is being derived from it. It’s like unused inventory, it is not yet realizing positive cash flow.
There’s another reason that unfinished work is considered waste in software development, and that has to do with task switching. It can take a lot of effort to come up to speed on a particular task, and when developers are asked to work on multiple projects at the same time there is a required ramp-up time where the developer is re-familiarizing herself with the task and is not yet productive. This ramp-up time can be quite significant when developers are asked to juggle several projects. It’s far more efficient to take a project from start to finish as quickly as possible. Not only does this eliminate the ramp-up time required on task switching but it also keeps us focused on delivering, as quickly as possible, value for the one feature we’re working on. Rapid delivery means rapid feedback, which means we’re not wasting our time working on tasks that aren’t needed.
Until a feature is coded, integrated, tested, and delivered, it is not providing value to a user. The sooner a feature can provide value to a user the better.
Until a feature is tested and integrated into a system it is not considered done. All the work that sits in a queue waiting for quality assurance to test it is considered waste. Any change to a system that requires additional QA effort turns existing code into waste until it is tested.
The way to eliminate this waste is to automate the process of verifying release candidates. Test-first development allows developers to create an automated suite of tests to validate release candidates so when the system is changed it can be verified with a keystroke.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
