In Lean, how does Eliminate Waste apply to software?

John Boal — Fri, 18 Sep 2009 05:21:55 GMT

Lean is one of the three legs of the Agile stool (Scrum, XP being the other two). Lean is a concept originally used by Toyota in manufacturing, and it has been adapted to software development. Lean, Scrum, and XP have some overlap, but they dovetail nicely together, and complement each other's practices to build a strong foundation for software production.

The main tenets of Lean are as follows:

Eliminate waste.
Build integrity into the product.
Enhance and promote learning
Deliver as fast as possible.
Decide as late as is responsibly practical.
Empower the team.
See the overall big picture

The elimination of waste is a critical point in streamlining processes. Waste in this context is anything that does not deliver value (from the CUSTOMER'S perspective). Writing a status report does not add value for the customer, so it would be considered waste, even though it may have legitimate business value.

Waste in software development is most easily recognized as one of the following.

Undelivered or incomplete work
Excessive Process
Extra features
Randomization (switching tasks or projects)
Movement (physically moving from one position to another)
Bugs

Incomplete work isn't shippable, so it is of no value to the customer. It most likely contains bugs also which are lurking below the surface, as it isn't completed yet (fully tested). This concept is applicable on scrum teams directly, by having the team focus on the topmost few stories in a sprint, and complete them (to a shippable and demonstrable state) before opening the next story. This guarantees complete units of functionality that the customer can value.

Some process is necessary in software development, this is computer SCIENCE after all, an ENGINEERING - not art or the wild west. However, process that doesn't directly add value (in the customer's view) are waste. Performance reviews, status reports, departmental request forms, etc. are all waste in this view. Having a checklist to satisfy and having a code review before check-in are NOT waste, they directly add value that a customer can appreciate.

Extra features are complete waste. It has been long known (and widely and variously quoted) that the majority of features are not used in most software products today. It's basically been the 80/20 rule - 80% of the people use only 20% of the features, and that's enough for them to make use of the product and be effective. The other 80% of the features are probably waste, because of the tremendous time and effort that had to go into building, testing, and maintaining them for a minority (sometimes a very lonely few) users. This time and effort should probably have been better spent.

Switching tasks, contexts, randomizations, and interruptions are another source of waste. This includes meetings, phone calls, IM's, etc. Anything that causes members of the team to have to stop thinking about the software and focus on something else. There is a time cost not only for the interruption, but for re-adopting the context and thought processes again when they return to development. Ideas and real progress can be lost this way. Schedule meetings for the last half of the day only, turn off the phone (YES your CELL TOO), email, and IM when working - this will help streamline the focus and eliminate waste.

Movement or motion is a great cause of waste. Not only does it take time, but it can be physically tiring too. If that developer has to walk down the hall 6 offices to ask someone a question and talk face to face, that takes a minute each way. Also, it's the opportunity to be distracted by other things going on, colleagues, a new cup of coffee, etc. Not that these are bad things - they aren't. However, it blocks the focus on development. Starbucks recently applied this concept to its stores, when it studied how much motion it took a barista to make a latte. They discovered that there were extra motions each barista had to make in reaching for the beans, getting out the milk, etc. They moved the beans up from the cupboard to the counter, and some other minor movement-lessening optimizations and saved a few seconds for each cup of coffee made. Overall, they saved several man-hours of labor each day at each store, got the customers coffee even faster, and saved some work for the baristas. This really is a powerful concept.

Bugs and rework are entirely waste. It wasn't done correctly the first time, so it now has to be done again. Study the reasons why your bugs happen, and make sure to track down the root causes and catch the trends. Make fixes around the holes in the processes that allowed the bugs to fall through. It is far more expensive to the customer and to the software producer to fix things early (like when a test fails) rather than after shipping. Think about Windows XP patches, there have been hundreds. If only 10% of them could have been prevented by more extensive testing, the product might have shipped only a few months later, but how many billions of dollars of IT time, download bandwidth, reboot time, and lost progress with the millions and millions of installed users. Not to mention the growing mistrust of the user community for the company.

Elimination of waste may seem like a simple thought, but in a software development process it can be rather complex and sometimes a bit hidden as to where waste may lie, and how to eliminate it. However, once we get this efficiency, we can lower the cost and time it takes to deliver better quality software to our customers.

Bits 'n Widgets - Lean

In Lean, how does Eliminate Waste apply to software?