Eliminate Waste
Defects → defects
This one is easy. A defect is a defect, whether you’re talking about manufacturing a physical product or developing software. Defects cause expensive rework, which is always non-valueadded waste. The focus in a Lean environment is on preventing defects, whereas traditional development focuses on finding defects after they have already occurred. Defects are especially expensive when detected late.
In Lean, when a defect is found, the response is to find the root cause of the defect and make changes that will ensure the defect cannot recur. In software development, this means having a suite of automated tests that prevent defects from slipping into the software undetected. When a defect does slip through, a new test is created to detect that defect so that it cannot pass through undetected again.
This one is easy. A defect is a defect, whether you’re talking about manufacturing a physical product or developing software. Defects cause expensive rework, which is always non-valueadded waste. The focus in a Lean environment is on preventing defects, whereas traditional development focuses on finding defects after they have already occurred. Defects are especially expensive when detected late.
In Lean, when a defect is found, the response is to find the root cause of the defect and make changes that will ensure the defect cannot recur. In software development, this means having a suite of automated tests that prevent defects from slipping into the software undetected. When a defect does slip through, a new test is created to detect that defect so that it cannot pass through undetected again.
Overproduction → extra features
Every line of code costs money. Over the lifetime of the software, the cost of writing the code is probably the smallest cost. The code must also be designed, documented, and maintained (changed, enhanced, debugged, etc.). This means that a cadre of current and future team members must repeatedly read and understand the code. The presence of the code must be taken into account in each future product change or enhancement.
The 80/20 rule applies in most software products: 80% of the user’s real needs are provided by 20% of the product’s features. This means the other 80% of a product’s features are rarely (or never) used. At the XP 2002 Conference, the Standish Group reported that 45% of features were never used and that only 20% of features were used often or always. In fact, a 2001 paper titled “Improving Software Investments through Requirements Validation” (IEEE 26th Software Engineering Workshop) found that in 400 projects examined over a period of 15 years, less than 5% of the code was actually useful or used!
Every line of code costs money. Over the lifetime of the software, the cost of writing the code is probably the smallest cost. The code must also be designed, documented, and maintained (changed, enhanced, debugged, etc.). This means that a cadre of current and future team members must repeatedly read and understand the code. The presence of the code must be taken into account in each future product change or enhancement.
The 80/20 rule applies in most software products: 80% of the user’s real needs are provided by 20% of the product’s features. This means the other 80% of a product’s features are rarely (or never) used. At the XP 2002 Conference, the Standish Group reported that 45% of features were never used and that only 20% of features were used often or always. In fact, a 2001 paper titled “Improving Software Investments through Requirements Validation” (IEEE 26th Software Engineering Workshop) found that in 400 projects examined over a period of 15 years, less than 5% of the code was actually useful or used!
Transportation → handoffs
If you have worked on large projects, this might sound familiar:
1. Analysts create a document containing all of the product’s requirements and hand it off to the architects.
2. Architects take the requirements and create the product design, which they hand off to the programmers.
3. The programmers write the code to implement the design and pass the results to the QA testers.
4. The QA testers validate the resulting product against the requirements.
This is a classic Waterfall process that is replete with handoffs. A tremendous amount of knowledge is lost through each handoff simply because it is not possible to record everything that was learned, discovered, created, and known in a written form. A large amount of tacit knowledge is not passed on.
This means that the architects won’t understand the requirements as deeply as the analysts, and that the programmers will not understand the design as well as the architects. This incomplete understanding will lead to errors and omissions, which will require costly rework to correct.
If you have worked on large projects, this might sound familiar:
1. Analysts create a document containing all of the product’s requirements and hand it off to the architects.
2. Architects take the requirements and create the product design, which they hand off to the programmers.
3. The programmers write the code to implement the design and pass the results to the QA testers.
4. The QA testers validate the resulting product against the requirements.
This is a classic Waterfall process that is replete with handoffs. A tremendous amount of knowledge is lost through each handoff simply because it is not possible to record everything that was learned, discovered, created, and known in a written form. A large amount of tacit knowledge is not passed on.
This means that the architects won’t understand the requirements as deeply as the analysts, and that the programmers will not understand the design as well as the architects. This incomplete understanding will lead to errors and omissions, which will require costly rework to correct.
Even worse, the knowledge loss is compounded with each handoff. For example, if you assume that 50% of the knowledge is lost in each handoff, the programmers only receive 25% of the original knowledge, losing a whopping 75% in only two handoffs! Try to avoid handoffs whenever possible.
Inventory → partially completed work
Simply stated, partially completed work is anything that has been started but not finished. This could be requirements (features) that haven’t been coded, or code that hasn’t been tested, documented, and deployed, or bugs that haven’t been fixed. Rather than letting partially done work build up in queues, the Lean approach uses single-piece flow to take a feature through to deployment as rapidly as possible.
A feature is not complete until it is potentially deployable (other constraints may not allow actual deployment as often as we would like), fully documented, tested, and error-free.
Simply stated, partially completed work is anything that has been started but not finished. This could be requirements (features) that haven’t been coded, or code that hasn’t been tested, documented, and deployed, or bugs that haven’t been fixed. Rather than letting partially done work build up in queues, the Lean approach uses single-piece flow to take a feature through to deployment as rapidly as possible.
A feature is not complete until it is potentially deployable (other constraints may not allow actual deployment as often as we would like), fully documented, tested, and error-free.
(Over) processing → unneeded processes
Unneeded processes are pure waste. They get in the way of productivity without adding any value. They include procedures that accomplish nothing and documents that no one reads. They also include manual tasks that could be automated and procedures that make simple tasks hard.
Unneeded processes are pure waste. They get in the way of productivity without adding any value. They include procedures that accomplish nothing and documents that no one reads. They also include manual tasks that could be automated and procedures that make simple tasks hard.
Build Quality in
One of Taiichi Ohno’s key manufacturing insights was that you cannot inspect a product for quality at the end of a production line. That approach detects problems, but it does nothing to correct them. Instead, each step in the process should be mistake-proof and self-inspecting.
When a problem is detected, the entire assembly line stops until the root cause of the problem is found and corrected (so that it cannot occur again).
A famous example is the New United Motor Manufacturing, Inc. (NUMMI) automobile factory, a joint venture between Toyota and General Motors. Toyota told workers simply to do good work and to stop the line whenever something prevented them from doing their jobs. It took nearly a month to produce the first vehicle, but since each problem was solved once permanently the plant quickly became a leader in quality and productivity in the U.S.
Traditional software development has followed the same pattern as traditional U.S. car manufacturing: let defects slip through and get caught later by QA inspections. The Lean approach is to mistake-proof your code by writing tests as you code the features. These tests prevent subsequent changes to the code from introducing undetected defects.
One of Taiichi Ohno’s key manufacturing insights was that you cannot inspect a product for quality at the end of a production line. That approach detects problems, but it does nothing to correct them. Instead, each step in the process should be mistake-proof and self-inspecting.
When a problem is detected, the entire assembly line stops until the root cause of the problem is found and corrected (so that it cannot occur again).
A famous example is the New United Motor Manufacturing, Inc. (NUMMI) automobile factory, a joint venture between Toyota and General Motors. Toyota told workers simply to do good work and to stop the line whenever something prevented them from doing their jobs. It took nearly a month to produce the first vehicle, but since each problem was solved once permanently the plant quickly became a leader in quality and productivity in the U.S.
Traditional software development has followed the same pattern as traditional U.S. car manufacturing: let defects slip through and get caught later by QA inspections. The Lean approach is to mistake-proof your code by writing tests as you code the features. These tests prevent subsequent changes to the code from introducing undetected defects.
Create Knowledge
The point here is not to forget the lessons you have learned. Obviously, making the same mistakes over again or relearning how something works is a waste of time and effort. And it’s not just you, your coworkers shouldn’t have to learn something you have already figured out. Find ways to record your team’s knowledge so that you can easily locate it the next time you need it. It’s hard to be specific about this because what makes sense and what will work for you is highly dependent upon the context. However, it is generally best to store a given piece of knowledge closest to its source.
The point here is not to forget the lessons you have learned. Obviously, making the same mistakes over again or relearning how something works is a waste of time and effort. And it’s not just you, your coworkers shouldn’t have to learn something you have already figured out. Find ways to record your team’s knowledge so that you can easily locate it the next time you need it. It’s hard to be specific about this because what makes sense and what will work for you is highly dependent upon the context. However, it is generally best to store a given piece of knowledge closest to its source.
Defer Commitment
The best decisions are made when you have the most information available. If you don’t have to make a particular decision now, wait until later when you have more knowledge and information. But don’t wait too long, either lack of a decision should not hold up other aspects of the project.
The best decisions are made when you have the most information available. If you don’t have to make a particular decision now, wait until later when you have more knowledge and information. But don’t wait too long, either lack of a decision should not hold up other aspects of the project.
Deliver Fast
Software development is an abstract endeavor. Yet most of us (including our customers) work best when dealing with concrete things. When we can see, touch, and feel something, it becomes real, and our brains can more easily think about what works and what doesn’t. Our imaginations can dream of features or capabilities that we didn’t realize we needed.
Software development is an abstract endeavor. Yet most of us (including our customers) work best when dealing with concrete things. When we can see, touch, and feel something, it becomes real, and our brains can more easily think about what works and what doesn’t. Our imaginations can dream of features or capabilities that we didn’t realize we needed.
This is why software requirements are so volatile. The Waterfall approach would have you waiting until the end of the project to get customer feedback based on the actual use of the software, and that is why the Waterfall process is so prone to failure. “Deliver fast” means developing features in small batches that are delivered to the customer quickly, in short iterations. These features can be implemented and delivered before the associated requirements can change. This means that the customer has an opportunity to use these features (which are now concrete) to provide feedback that can change the other requirements before they are implemented.
The completion of each short iteration provides an opportunity to change and reprioritize the requirements based on real feedback and use. The end result is a product that more closely meets the real needs of the customer, while simultaneously eliminating the tremendous amount of waste and rework created by the requirements churn—truly a win-win situation.
The completion of each short iteration provides an opportunity to change and reprioritize the requirements based on real feedback and use. The end result is a product that more closely meets the real needs of the customer, while simultaneously eliminating the tremendous amount of waste and rework created by the requirements churn—truly a win-win situation.
Respect People
This is a lofty altruism that is also the down-home truth. As Mary and Tom Poppendieck said in Implementing Lean Software Development, “Engaged, thinking people provide the most sustainable competitive advantage.”
Respect for people means trusting them to know the best way to do their jobs, engaging them to expose flaws in the current process, and encouraging them to find ways to improve their jobs and the surrounding processes. Respect for people means recognizing them for their accomplishments and actively soliciting their advice. Don’t waste your most valuable resource—the minds of your team members!
This is a lofty altruism that is also the down-home truth. As Mary and Tom Poppendieck said in Implementing Lean Software Development, “Engaged, thinking people provide the most sustainable competitive advantage.”
Respect for people means trusting them to know the best way to do their jobs, engaging them to expose flaws in the current process, and encouraging them to find ways to improve their jobs and the surrounding processes. Respect for people means recognizing them for their accomplishments and actively soliciting their advice. Don’t waste your most valuable resource—the minds of your team members!
Optimize the Whole
This is an important part of Lean thinking no matter where Lean is being applied, and Lean software development is no exception. Whenever you optimize a local process, you are almost always doing so at the expense of the whole value stream (this is suboptimizing). If you don’t have control over the entire value stream, you may be forced to suboptimize a piece of it. In general, though, you should always attempt to include as much of the value stream as you can when you try to optimize a process.
This is an important part of Lean thinking no matter where Lean is being applied, and Lean software development is no exception. Whenever you optimize a local process, you are almost always doing so at the expense of the whole value stream (this is suboptimizing). If you don’t have control over the entire value stream, you may be forced to suboptimize a piece of it. In general, though, you should always attempt to include as much of the value stream as you can when you try to optimize a process.
Nice article. You mean to say is to follow agile software development process
ReplyDeletegood post. Thanks
ReplyDeleteNice Post. Thanks for sharing & keep it up.
ReplyDelete-------------
Application Development Company India
Very nice - easy to follow, simple, and working. Thanks for the knowledge!
ReplyDeletePay per click
In the manufacturing industry, the importance of software is just as important as the equipment and manpower used in every stage of the whole process. That's why it's important to scrutinize each of the software before integrating it into the production. CRMs and ERPs should be able to provide the requirements that are asked of.
ReplyDeleteWoooooooooooooooooooooooooooooow /Hey thanks man!! you are so good. I think this the perfect work.
ReplyDeleteSoftware Product Development