in

Ative at Work

Agile software development

Ative at Work

Lean Principle Number 1 - Eliminate Waste

The key principle in lean manufacturing is to eliminate waste.

The Toyota Production System names seven major sources of waste. Mary and Tom Poppendieck list these in their book Lean Software Development - an Agile Toolkit (Addison-Wesley, 2003) with the translation to software development:

The Seven Wastes of Manufacturing

The Seven Wastes of Software Development

Inventory

Partially Done Work

Extra Processing

Extra Processes

Overproduction

Extra Features

Transportation

Task Switching

Waiting

Waiting

Motion

Motion

Defects

Defects

Partially Done Work

Partially Done Work is a frequent cause of failure in many projects. It usually begins with the best intentions such as creating expert teams for each layer in the application. Put a database team in one room and the middleware team in another room and the application team in the next building and plan single big-bang integration phase in the end of the project and you have a recipe for disaster. The experience from lean manufacturing is that it is faster to do single-piece flow and finish a feature completely rather than taking in the overhead of managing huge batches of work-in-progress. It also takes out a lot of the risk since we are always 100% done with x% of the application - not x% done with 100% of the application. This permits us to realize the cost savings or extra revenue of the feature early rather than later. The key is to integrate early and often, deliver incrementally and manage the product lifecycle thinking in small releases.

Extra Processes

It also relates to Extra Processes. Many of the practices of "professional" software development organsations are needed only to provide a sense of control while not addressing the underlying problem. It is like repeatedly shooting yourself in the foot and then priding yourself on how your organisation's surgeons are really good at patching it up afterwards.

Examples of extra processes include all kinds of requirements, analysis, design, and test documents that no-one will ever read, the endless meetings with more people than are really needed or all the bureaucratic inventions to prevent change - Change Control Boards, reviews, complex ISO and CMMI processes that make simple work hard. It also includes the manual tasks that should be automated but are not (see Setting a Minimal Professional Standard http://community.ative.dk/blogs/ative/archive/2006/12/10/Going-Agile-_2D00_-Setting-a-Minimal-Professional-Standard.aspx). In short, extra processes are all the work that intelligent people wouldn't do without being told.

For example, one particular system we worked on had a rigorous ISO process for change control that made it practically impossible to fix anything that had gone through all the reviews. In one case, we discovered a private member of a class that should have been publicly accessible - something that is very easy to fix if there are no extra processes. However, since the module was already reviewed and "finished" the process required us to change the code, rerun all the test cases, copy the output into a Word document, go through a review meeting and update a host of documents. All this for changing the word "private" to "public" in a single source file. Needless to say processes like this drives up the cost of software development dramatically and in many cases the only business value is being applauded by the ISO auditors for following the process very rigorously.   

Extra Features

The easiest way to finish faster is to write less software. The oft quoted Standish Group study from XP 2002 concluded that 45% of features in a typical application were never used and only 20% of features were used often or always. A good Product Owner with an iterative, incremental process can leverage this to get dramatic cost savings by simply building the most important features first and stopping the development process when the marginal value of extra features no longer justifies further investment. Also, by delivering incrementally we can start learning generating ROI on the most valuable features faster - and learn about the system so we are better able to prioritize the remaining work. A further benefit of delivering only the essentials is that we end up with a smaller, simpler code-base which is easier to change and evolve - which means we can go faster in the future since we are no longer carrying a huge burden of non-productive weight.

Task Switching

Task switching is another common productivity killer. Programmers know the state of "flow" where work is focused, efficient and effortless. It takes a while to get into this state. This is one of the reasons that single-piece flow is such a great way to work: we start something, we focus and we finish. There are no interruptions and context switching to disturb us from getting into the state of flow and we free up all the resources we would otherwise use to track all our bits of work-in-progress. 

In many organizations task switching is caused by sharing people across multiple teams. For example, on one project I worked with an analyst who was 50% allocated to another team. After a while he came to our status meeting and told the project manager that they should not expect much output from him on any of the teams: he almost was fully booked just by attending all the meetings in the two teams. Here, focusing on one team for one sprint at a time was much more efficient.

Waiting

Waiting is another waste. If it takes three hours of work to accomplish a certain feature you should not have to wait four months to have it delivered. This is a waste. The anti-dote provided by lean is to use value stream analysis to look at the value stream of the whole development process from the customer's perspective and comparing the hours of work done to the waiting time (calendar time) from the moment the concept is conceived to the moment the feature is delivered. In many organizations the efficiency of the production cycle - the work effort compared to the time it takes to complete the process - is less than 1%. Most of the features spend their lives sitting in queues, waiting for the next Change Control Board meeting, living in Requirements documents, waiting in Analysis documents before being implemented, waiting for system integration, waiting for the testers to test them, or waiting in a bug tracking system to be corrected or waiting for the next bi-annual deployment window. All this waiting time accumulates Partially Done Work, causes us to introduce complex procedures to manage it and adds no business value to the customer. Therefore, it must be eliminated.

The approach here is to take a simple approach. If you need it - build it now. Select only the most valuable features then deliver them quickly. Match the in-flow of tasks and the production capability. Specifically think about your team like you dimension your server hardware and don't try to run it at peak utilization. In fact, the highest efficiency is generally found when there organization is running at no more than 80% utilization since this provides much better latency.

Motion

Motion is one of the other wastes. It occurs when we need to go somewhere else to solve a problem - if the customer or an expert is not at hand when we need answers to questions or if the team is spread out over multiple offices, floors, buildings or even time-zones. (We have written about this in Refactoring the Physical Workspace http://community.ative.dk/blogs/ative/archive/2006/10/13/Refactoring-The-Physical-Workspace.aspx). It also happens during the many hand-offs that are so typical in waterfall development. One person writes the requirements, then an analyst translates it to something for the technical team, then another person takes over and interprets it to code it etc. The documents that are handed over at each step will never be adequate. The cure is not to write more detailed documents since this takes even longer and only provides a false sense of security. The best cure is simply to eliminate the hand-offs altogether and have developers and customers sit together to figure out what needs to be done, code it up as an acceptance test and implement the code to make it pass quickly.

Defects

This also leads to the last of the wastes: defects. As a rule of thumb, the longer a defect is allowed to stay in the system, the more it costs to fix it. First of all there is the risk of change, we might have to do a costly recall, repeat a lot of manual testing, revise the documentation etc. On the other hand, if we fix the bug immediately, or even better - if we don't allow it to come into the system in the first place we reduce the cost of fixing the defects to almost zero. The key here is to realize that software with defects is work-in-progress. This is the reason that test-driven development and automated regression test suites are among the key practices of lean software development teams. In fact, preventing defects is so essential that we will devote a whole article to it shortly. Stay tuned.

 

Published jan 18 2007, 12:16 by Martin Jul
Filed under: , , ,

Comments

 

deployJava » Lean Principle Number 1 - Eliminate Waste said:

januar 22, 2007 12:43
 

Mark Seemann said:

Hi guys

Can you please, PLEASE change your feed back to full articles?

Your last five articles have only been syndicated in excerpts, which makes them unreadable in an aggregator :(

januar 24, 2007 9:29
 

Martin Gildenpfennig said:

Hi Mark

I have made a configuration change, so you should be getting full articles for future posts.

januar 26, 2007 9:53
 

Martin Jul said:

Raymond Lewallen wrote on waste in software development here:

codebetter.com/.../identifing-waste-the-lean-way.aspx

september 7, 2008 4:26
 

Toyota Guy said:

Your translation of Muda works well but is only a part of the equation when eliminating waste. According to my Japanese Sensei (nickname Joe), there are the other 2 other "M's" in addition to Muda you would want to consdier to make this a more complete approach that collectively describes wasteful practices to be eliminated.

Mura: Unevenness in an operation; for example, an uneven work pace in an operation causing operators or processes to hurry and then wait.

Muri: Overburdening equipment, processes or operators.

Hope this helps - Happy Hunting

april 5, 2009 5:24
 

Lean Manufacturing Techniques said:

Many people came to work today to spend their time on waste? Some maybe! But not most. So what is waste, and how do you identify it?

Some waste is obvious. But other forms of waste are more difficult to spot or to solve. I’m sure in most organisations it’s sometimes very difficult to identify what is waste and what is not. Some processes or conventions might seem wasteful, but actually provide real value elsewhere in the organisation, or prevent other forms of waste from emerging later. Other activities may seem valuable, but actually do not really result in any real value.

januar 11, 2011 12:17
 

Martin Jul said:

You are absolutely right that it is often difficult to identify the waste. If it were, I am sure it would have been already removed.

The root cause is frequently that the causal dependencies between the things we do and the downstream outcomes are not always clear.

Sometimes the scientific method is the great arbiter. You can make an experiment with a control group and measure the impact of what you do compared to not doing it.

However, in my own experience, and this is what I heard from the lean senseis at Toyota as well, you often don't need statistical analysis and the whole apparatus.

If you map out the value stream - all the activities that go into producing a certain product, and try to relate them to how they create value for the customer, a lot of the waste becomes very clear.

It is often hiding in interactions between departments.

For example, there is often a great deal of management work related to planning and scheduling so each department can maximise its utilization, rather than maximizing the value creation flow across departments.

For example, we worked with a company that had a very expensive bug tracking system and detailed change management processes with executives meeting to prioritize which defects should be fixed first.

We did a multi-year project with this company and eliminated the need for that whole process. By keeping the software at a constantly high quality the list of open issues was tracked on post it notes, and since the turn-around time on fixing anything that was found was on the scale of hours, there would be no bugs to prioritize in the executive meeting.

The bug tracking system and the bureaucracy around it was suddenly waste.

Of course, if the organisation is routinely creating defective software it may be better to have the process in place, so it was surely invented to save resources and improve the outcome, but it was hinged on low quality.

When the quality improved, a lot of the bureaucracy became obsolete.

Therefore, we should always strive to improve quality and revisit our assumptions - why are we doing this? what would need to change to make this unnecessary?how can we make this activity obsolete?

Once it becomes clear that you have a lot of bureaucracy BECAUSE your quality is low it points very clearly to where you should start if you want to remove the waste.

Starting the other way around just makes you look like a fool since you have the sickness and you just suggested to not even try curing the symptom.

januar 11, 2011 10:17
 

Fernando Carvalho said:

What is waste?

First you need to realise what you costumer realy want, and pay you to do.

Next, you must focus on do just what you're paid to do.

Code is one, for instance.

How can you work with the minimum stock possible?

You must realise that many requirements are inventories, and you must work with only one at a time.

In order to resolve only one requirement, how many documents you need? How many handoffs you need?

Working with only one requirement, temporary forgeting every thing else, you will find what is absolutaly necessary to produce that one requirement, and what is waste.

Hope it helps.

januar 20, 2011 10:35
 

Martin Jul said:

Hi Fernando

Thanks for the excellent input. It is very good advice and very actionable.

Thanks a lot for sharing.

Martin

januar 30, 2011 11:13

About Martin Jul

Building better software faster is Martin's mission. He is a partner in Ative, and helps development teams implement lean/agile software development and improve their craftmanship teaching hands-on development practises such as iterative design and test-first. He is known to be a hardliner on quality and likes to get things done-done.
© Ative Consulting ApS