In The Toyota Production System Taiichi Ohno says that capacity = work + waste. And that one should strive for absolute elimination of waste. When you are thinking about the absolute elimination of waste one should always keep the following 2 points in mind:
1. Improving efficiency makes sense only when it is tied to cost reduction. To achieve this, we have to start producing only the things we need using minimum manpower.
2. Look at the efficiency of each operator and of each line. Then look at the operators as a group, and then at the efficiency of the entire plant. Efficiency must be improved at each step and, at the same time, for the plant as a whole.
The efficiency can be quantified in the following fashion: efficiency = work / cycle time.
At Toyota they identified the 7 following types of waste:
- Overproduction
- Unnecessary transportation
- Inventory
- Motion
- Defects
- Over-processing
- Waiting
Now in order to eliminate waste we first need to identify waste. It is my experience that there are some recurring problems when in comes to developing software. When looking for waste we need to look at it at 3 different levels. In software developed we can look at it from a Team Member’s perspective, Team and process.
Overproduction
Overproduction happens each time you engage more resources than needed to deliver to your customer. For instance, large batch production, because of long change over time, exceeds the strict quantity ordered by the customer. For productivity improvement, operators are not required to produce more than the customer needs. Extra parts will be stored and not sold. Overproduction is the worst muda because it hides or generates all others, especially inventory.[citation needed] Overproduction increases the amount of space needed for storing raw material as well as finished goods. It also requires a preservation system.
In software production overproduction can be seen as developing features that are never going to be used. At XP2002 Jim Johnson of the Standish Group reported that a study on the functionality in software. The graph below clearly shows that 64% of the functionalities build is barely used! In the past I had a lot of discussions with my colleagues about this… If a customer asks something its not necessarily mean that he actually needs it.
“If I had asked people what they wanted, they would have said faster horses”
Henry Ford
One way to avoid this is to release as early and as often as possible. This enables immediate feedback from the actual end users. Overproduction is quite frequent in when the QA department is not a part of the team. Since in most companies the QA department usually has more work than it can cope with people try to produce large batches to send to them only adding to their workload hiding possible defects. In the past I worked closely with a development team to enable them to release multiple versions a day to the test environment. This immensely improved the quality.
Something that pays of (with interest) is to invest in your deployment strategy and not wait until the very last moment. I have seen it to many times that this is neglected and every time a new environment needs to be deployed it takes a lot of manual manipulations of various configuration settings making deployment a very erroneous activity. To counter this people would only release large batches of bug fixes and features. This obfuscates a lot of problems like a bug that works on a developers machine but not on an other environment. In the worst case these problems only show up when deploying to the production environment -since in most companies this is done by different people who are not aware of configuration changes for example – causing downtime.
Unnecessary transportation
Each time a product is moved it stands the risk of being damaged, lost, delayed, etc. as well as being a cost for no added value. Transportation does not make any transformation to the product that the consumer is supposed to pay for.
In software development the product is not only the piece of software we have written but more so the knowledge required to operate and write the software.
According to Poppendieck transportation are handoffs of knowledge . When transferring knowledge from one person to another the most effective way of doing this is by face to face communication. far less effective – in declining order – are phone calls, emails and documentation. Examples of this are requirements documents, bug reports. This however does not mean it is a waste to write them, it means you have to keep them as lean as possible and facilitate communication between the people that have the knowledge.
Even with face to face communication a lot of knowledge is lost. To quote Freud: “The things that go without saying are usually left unsaid…”. This can easily be perceived with playing a game somebody says a sentence to the person left of him who in his turn tells it to the person to his left and so on. Could be done in the form of “I am going on holiday and I take the following things with me:” and everyone adds one item to the sentence and the next person has to repeat the whole list, if he makes a mistake he can no longer participate in the game. See how long the list is before every one made a mistake, than compare it to your requirements documents.
Other sources of waste can be branching (if its to complicated) since it also requires transportation. If you have to many branches the knowledge is lost every time you have to transport it from one branch to another. Integrate your code early and often! It is a lot better to merge your changes on a daily basis than on a 2 weekly basis!
Inventory
Inventory, be it in the form of raw materials, work-in-progress (WIP), or finished goods, represents a capital outlay that has not yet produced an income either by the producer or for the consumer. Any of these three items not being actively processed to add value is waste.
Take for example a developer sends of some code to the deployment team who has the responsibility to deploy to the test environment than from the developer’s perspective the work is done. Then its somewhere in the queue of the deployment team waiting to get in the queue of the test team, building up inventory. Then when the testing team finally got round to testing it they discover some bugs and the functionality needs to be reworked. This largely depends on the teams definition of done. If an impaired Definition is used a team will never reach an hyper productive state. This is usually reflected in Acceptance testing cycles only just before each release (encompassing several iterations).
To avoid inventory to build up remove impediments and allot some time to “Groom” the backlog (e.g. Remove items from the backlog that are older than 16 weeks). This is a very hard concept for people to understand but don’t build up inventories. If a backlog is consistently prioritized the items older than a certain period nobody will probably remember them after one year anyhow.
Motion
As compared to Transportation, Motion refers to the producer, worker or equipment. This has significance to damage, wear and safety. It also includes the fixed assets and expenses incurred in the production.
This can be taken quite literally. One of the biggest tips I can give you is sit the Team together! This facilitates osmotic communication, the added value of removing physical distance is immense even with distances more than 2 meters. If somebody has to turn or get up from his desk to ask a team member a question he will not do it.
Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work
Cockburn 2004
A lot of teams underestimate the impact of context switching. The productivity of someone declines rapidly if he or she are combining multiple tasks. As the graph shows below multi tasking kills productivity. When someone is working on a single project his productivity is around 70% the remaining 30% is absorbed by something Mike Cohn good citizenship (socializing with colleagues, administrative duties, reading mails, …). This is in line with what Henrik Kniberg calls “Focus Factor”.
Source: Steven C.Wheelwright and Kim B.Clark (1993), Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality
Defects
Whenever defects occur, extra costs are incurred reworking the part, rescheduling production, etc.
When defects appear these need to be detected and resolved as quickly as possible. Find below a table of a the relative cost associated with the stage a defect is detected:
| Requirements development (Vision) | 1x |
| Design (Writing the User Story) | 2-3x |
| Construction (Development) | 5-10x |
| System Or Acceptance Testing | 8-20x |
| Production | 68-110x |
| Boehm 1981; Grady 1999 |
Usually the primary goal of testing is to discover errors, but teams should strive to do testing to prevent errors. This is what XP, TDD and BDD propagate, all code flows from a test. Once you are a TDD adept like me there is no other way you want to write code. It is usually very hard to convince people about the added value of writing test code (they see it as wasted effort). Invest in automated test frameworks and/or tools.
A great tool to signal an abnormality is some kind of “Andon” a visual indication that something is wrong visible to the whole team. If a build fails the first thing anyone who notices this should Stop what he is doing Fix the issue and investigate the root cause of the failure. And not look who checked in the last bit of code and points his finger in the direction of whoever caused the failure. Continuous Integration asks for a fair bit of discipline but is worth its weight in gold.
The purpose of continuous integration is not have a 100% success rate, studies have shown that the sweet spot is around 67% success rate to maximize productivity (according to Jeff Sutherland). Examples of Andon’s are for example CC tray, Team Build Notification, small tools running on an unused piece of hardware that is visible to everyone, lava lamps, traffic lights,… less obvious examples are Scrum/Kanban Boards.
If an abnormality is detected it should be fixed immediately otherwise the broken windows syndrome will kick in. This means that the defective state will be considered as a normal state.
Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it's unoccupied, perhaps become squatters or light fires inside.
Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of trash from take-out restaurants there or breaking into cars.
Broken windows: James Q. Wilson and George L. Kelling (1982)
Over-processing
Over-processing occurs any time more work is done on a piece than what is required by the customer. This also includes using tools that are more precise, complex, or expensive than absolutely required.
Spending more time on something does not necessarily augment the quality nor does it add value. Do just enough. Developers have a tendency to over engineer solutions – also known as gold plating. In my experience most often too much time is often spend on premature performance optimizations, trying to solve concurrency resulting in complex multithreading code that quite quickly become complex and buggy choking points in an application. I frequently encounter developers that suffer from the not invented here syndrome, writing their own data access logic, logging, user controls… These things have been done over and over again by people before them but they stubbornly believe they will do it better than the legions of developers before them.
Writing code that can become useful in “future”. One thing they forget is that if you make this consistent behavior their might not be a future for your project. I always try to keep de following sentence in mind “Simple is already complicated enough”, or to quote Einstein “Make things as simple as possible, but not simpler…”.
Successfully delivering software projects are not achieved by writing code that is really cool to write but by just restricting yourself to the bare minimum to turn a requirement into a working bit of software. In the passed I was writing a kind of address book application that had to synchronize data from the ERP system to active directory. After struggling a few hours trying to write a windows service that had to run on regular intervals, I wound up writing a console application that I scheduled in the windows task scheduler.
Another thing that falls under this category is writing unnecessary code. Whether you have been writing this code or the code is generated by a tool (Code generators, Snippets, T4 templates etc, etc,…) is all the same. If you have repetitive patterns in your code try to look at design patterns, object oriented principles whatever and refactor them out. Every line of code that gets into your code base is a line of code you drag along for the rest of the life of the product.
Waiting
Whenever goods are not in transport or being processed, they are waiting. In traditional processes, a large part of an individual product's life is spent waiting to be worked
Waiting is an obvious waste, although an obvious one a very common source of waste and they reside very stubbornly in an organization or process. I can not count the times I heard there is nothing we can do about that, it always was this way. Although upon prying to the root cause no good reasons can be given to sustain these impediments. Often very strong indicators of suboptimal communication path ways by sending mails, filling out forms… Waiting occurs a lot in teams that do not successfully self organize or are not cross functional. Bottlenecks are often enforced by formal approval procedures, the lack of mandate by a team, lack of access to the QA department that has to perform Acceptance testing. These impediments can however be easily overcome by a simple value stream map which will quickly show bottlenecks in the process.
References
- Agile estimation And planning by Mike Cohn
- Lean Software Development: From Concept To Cash by Mary and Tom Poppendieck
- The Toyota Production System by Taiichi Ohno
- Wikipedia
No comments:
Post a Comment