Lean Tools: Seeing Waste

Every developer that has heard about the Lean movement knows that there are seven lean principles to use as a foundation for this approach in every industry - from manufacturing to software development. However, principles are often too generic to be easy to apply: the book Lean Software Development provides thinking tools that implements all the principles in our field of operations.

The first principle is called Eliminate Waste: intervene to remove from the process everything that does not add value to the final product. How many times have we draft a document or a presentation just because it was customary to write it for every project?

Today we will see the first of the tools for implementing Eliminate Waste, called Seeing Waste.

The Seven Wastes

Mary Poppendieck defines the Seven Wastes of software development, as categories of work that are not part of analysis nor of coding, and do not provide value for your customer, which may be the user of the product of the manager which decide sales in other companies.

Partially Done Work

Also called WIP (Work In Progress), this waste is identified with all partially developed features or stories. Examples of WIP are features which are:

• fully specified in a big document, but not developed yet.
• Checked in, but not tested yet.
• Unit tested, but not yet integrated with the rest of the system.
• Integrated, but not yet released or deployed where a customer can use it.

These features are in a limbo, and won't provide any value to the customer until they reach him. Meanwhile, we are paying the burden of a bigger codebase, and accepting the risk that in the time that it takes to complete the feature the goals of the user will have changed, making part of our efforts useless. You won't deliver a Black Friday shopping application in December; the utility curve of other features is not usually so sharp, but the more is shifted into the future, the less its present value.

Extra Processes

At least in the realm of taxes and contracts, everyone of us has experienced a form of paperwork that does not provide value. There are special requirements like conformance to a standard that require these processes (otherwise it may be illegal or impossible to sell a copy of the software), but we should take a shot at every development step that is performed out of habit instead of out of need.

Extra Features

In line with Agile processes, the lean approach tells us to stay in line with what a story requires to be implemented, and not to add any extra feature. It is tempting to put in something more than what is required now due to a lower transaction cost: in case we are asked, we won't have to rework the same code two days later. However, it is also often the case that we will be requested a different change making what we did obsolete, or that the feature will already work as-is without a refinement: meanwhile, we will pay the costs of our wasted time implementing the extra and of a bigger codebase to maintain.

Task Switching

Every time we switch between activities, there is a setup time to pay to get up to speed in the new one. This is true in manufacturing but also in knowledge working: we need to focus on our new task, open the necessary tools and find the right files. It's like warming up a mind cache, which is initially full of unrelated knowledge.

Waiting

A software that suffer performance problems often contains many threads which are blocked waiting for some resource to be available or some operation to finish (think about database and network calls). The same is true for a software development process: if we are waiting for a couple of days everytime we ask a question to an external person, we will waste much time waiting - while if we had this person in the same room with us we could enjoy a faster feedback.

Motion

People and items move around during a project - but as in networking, the more things you move, the more you slow down. A requirements document that move between the customer and the developers multiple times is waste not only in the waiting times that it produces, but also in the sense that some of the tacit knowledge surrounding the document is lost. Suppose I talk with the customer and draft a document with a list of all he needs; I give you the document and never participate to development again. Won't you prefer to have talked to the customer directly?

Defects

Each bug that gets to the end user is a waste: not only the user loses his own time, but the bug tracking means new tickets have to be created, we have to find which part of the code is causing the issue, and a new release has to be created. At the same time, it's very easy to fix a bug if you discover it in a few minutes: it can only have been introduced by the code you are working on; thus we can think of defects as waste that grows with the time they stay in the code without being corrected.

Project examples

Since I often use open source projects as a test bench for new techniques, I tried to collect examples of waste in my PHPUnit_Selenium project, a library for browser-based testing from PHP code.

• Partially Done Work: I am trying to maintain the lead time of a feature as lower as possible, with a release every 2 or 3 weeks at maximum. The software itself is always kept releasable, and fortunately with PEAR is very easy for users to update their copy with a single command.
• Extra Processes: releasing means also compiling a package.xml file which simply lists every file contained in a folder. There is currently no simple solution for regenerating this file, and it has already been the case that a file got missing in the list causing a break. I now have an automated check, but I wonder if this update could be easier.
• Task Switching: even when I have to fix a single one-line bug, starting to work on the code needed several tasks:

java -jar selenium-server.jar
cd code/phpunit-selenium/selenium-1-tests
python -m ...

which means I have to start a Selenium Server, and a local HTTP server to access some static pages. Continuous Integration opened up my eyes on this, and now I have a single script to start all of that. I did not eliminate task switching, which would be preferrable, but at least I am containing its cost.

• Motion and Waiting: fortunately, an open source project of a small scale does not have these problems. There is a case that is always present however: conversations on bug trackers. My standard response in case of a difficult to interpret ticket is something like:

Please include a test subclassing Selenium[2]TestCase that fails while exposing this bug; does this affect only a particular version?

because I am trying to minimize the number of answers I need from a user. Posting on a web page is not a phone conversation, and each response may take a day to arrive.