What is Waste?

Added to Technology

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.

What is software waste?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 tasks 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.

 

About the Author

David Bernstein has coached and trained more than 8,000 software developers from several Fortune 500 companies in the course of his 30-year career. His new book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software (http://BeyondLegacyCode.com), covers the core technical practices for developing software. A longtime special consultant to IBM, David trained IBM software engineers around the world, giving them the skills to write the next generation of applications and operating-system software, and earning one of the highest satisfaction ratings in the history of IBM corporate education. He is the creator of a wholesale bank-accounting software program that has become the de facto standard across the globe, as well as econometric software used to invest trillions of dollars. Over the past five years, David has coached and trained thousands of developers at Microsoft, Boeing, Vanguard and dozens of other companies in Agile development practices. David is the founder of To Be Agile, a Registered Education Provider for the Scrum Alliance, and trains Certified Scrum Developers in Scrum and XP development practices. To see a list of pubic classes offered by To Be Agile, go to http://ToBeAgile.com/training. You can contact David Bernstein at (206) 792-9700 or visit http://ToBeAgile.com. David’s blog can be found at http://ToBeAgile.com/blog. You can follow David on Twitter under his account @ToBeAgile (http://www.twitter.com/ToBeAgile). - See more at: https://www.scrumalliance.org/community/profile/dbernstein#sthash.td91w4KW.dpuf


This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.