The 7 Sins of Software Development

Waste elimination is one of the Lean principles and one of the most effective ways to increase quality and reduce cost. While products and services differ between industries, waste or muda – everything that does not add value from the perspective of the customer, or any material/resource beyond what the customer requires and is willing to pay for – can be found in any type of business, such as in the software development.

Mary and Tom Poppendieck – two of the leaders in describing how to implement Lean to software development – have translated the well-known “Seven Wastes of Manufacturing” into “The seven Wastes of Software Development”.

1. Partially done work (in Mfg.: Inventory): refers to any partially done software (Work In Process) that is not checked-in, integrated, tested, or deployed. Until that partially done software is integrated with the rest of the software development and then released into production, you don’t really know if it will eventually work or solve the business problem defined weeks/months ago; maybe at the time of release it is already obsolete resulting in a huge financial problem. In addition, partially done software gets in the way of other developments, so any work that is not finished triggers, for example, huge delays in the development (Waste #6).

2. Extra features (in Mfg.: Over-Production): refers to any feature added to the final product that the customer doesn’t need, want or even ask for. Any extra feature increases an unnecessary complexity, adds a potential failure point, and maybe it will become obsolete before is used. Not forgetting that as any feature, it has to be tracked, compiled, integrated, tested, and lifetime maintained.

3. Relearning (in Mfg.: Extra Processing): the first approach for this waste was Extra-process that focused on extra activities done that do not add value like excessive documentation or customer’s signoffs. After more understanding of this waste, it has been modified with the name of Relearning,referring to repeating a value adding activity spending time relearning things we have already learned. e.g.: undocumented code force to a new developer to “relearn” what was already learn for the previews programmer; a solution of an undocumented problem solved have to be relearn when the problem reappear.

4. Handoffs (in Mfg.: Transportation): refers to knowledge lost every time you hand a deliverable off to any team member (analyst, designer, programmer, tester, etc.). It’s estimated that approximately 50% of tacit knowledge – know-how possessed only by an individual and difficult to communicate to others via words and symbols – remains with the creator of the document and never get handed off to the receiver.

5. Task switching (in Mfg.: Motion): refers to time wasted when the same resource is assigning to multiple software projects. A person who have to switch from project A to project B needs a lot of time preparing himself – fiscally and mentally – and setting the environment to start working on project B. If that time is not considered in the project estimation, it will be difficult to finish both projects on stated dates. Thus, the Lean principle “Delivery as fast as possible” will not be accomplished.

6. Delay (in Mfg.: Waiting): refers to waiting for things to happen. That introduces discontinuity, triggers the appearance of all the other wastes, and keeps the customer from realizing value as quickly as possible. E.g.: delay in get the team conformed, waiting for approvals, delays due to excessive requirements documentation.

7. Defects (in Mfg.: Defects): refers to any error, bug, failure that produces an unexpected result. The formula the Poppendiecks use to quantify the amount of waste caused by a defect is: WASTE = Defect Impact * Time defect goes undetected. They said that a critical defect that is detected in 3 minutes is not a big source of waste as a minor defect discovered weeks later.

CONCLUSION

Out there are tons of tools we can use to eliminate wastes, but first of all we have to learn to see waste, a non-easy activity. Of course, there is no “silver bullet” to solve waste problems, but regardless of the methodology you use in your software company – CMMI, Agile, PMI, or a hybrid of all of them – Lean principle ‘Eliminating waste’ has huge value to get better quality, reduced cost, and faster delivery.

The more you learn about Lean, the more you will realize how much value has it when applying to software development projects. Let’s do a quick test: pick one of the wastes and see if you can identify activities in your job that do not add value and can fit perfectly under that waste umbrella. 

What it would be the best way for you to get rid of those activities? Share your thoughts!

REFERENCES
– Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck – 2003

– Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck – 2006

NOTE

Originally, I wrote this article for Christian Paulsen ’s Lean Leadership blog.

Image provided by: digitalart – FreeDigitalPhotos.net

Lean Software Development Principles

Lean Software Development (LSD) is a term originated from a popular book by the same name, written by Mary and Tom Poppendieck. In such book, they presented the first translation of Lean principles to software development, plus 22 thinking tools to help translate those principles into agilepractices. Having its roots in the well-known Toyota Production System, LSD focuses on helping software development companies to optimize their process, solving problems that old methodologies like waterfall have, and delivering software with better quality, reduced cost, and faster delivery.

Let’s do a review of the 7 LSD principles:

1. Eliminate Waste: take out all activities that do not add value from the perspective of the customer; in other words eliminate any material/resource beyond what the customer requires and is willing to pay for. The 7 Sins of LSDare:  Partially done work, Extra features, Relearning, Handoffs, Task switching, Delay and Defects.

2. Build Quality In: Mistake-proof your code from the beginning to prevent appearance of defects late at the end of the process.  One tool used to do that is test-driven-development where developers write unit and acceptance tests before they write the associated code. Coding and testing the system as often as possible working with short iterations, helps to reduce the appearance of defects late in the process. You can consider your development process defective if you assume that verification process is the only time when you could find defects, queue them (partially done work, waste#1) and then perform almost endless test-and-fix cycles.

3. Create Knowledge (aka Learn constantly or Amplify learning): “Planning is useful. Learning is essential”. Software development is a knowledge-creating process; recording the team’s knowledge is an efficient way to reduce waste of relearning and make the tacit knowledge more explicit and available for everyone. Also, software development is unpredictable so we shouldn’t base our development process on a plan considering it as a fact (can we predict the future?); we should take it as a forecast and work with short cycles, change-tolerant codes, and iterations with refactoring – improving the design as the system develops- so we can generate knowledge, have quickly feedback, and prevent of making early-irreversible decisions. In that way, you will have a development process that encourages systematic learning throughout the development cycle, so we can respond quickly and correctly to events as they occurred, delivering more predictable outcomes.

4. Defer Commitment (aka Decide as late as possible): the more information you have, the better decisions you make. Developing a robust, change-tolerant design and schedule irreversible decisions for the last moment until uncertainty is reduced and before it is too late, is the best option to not being locked in a critical design decision made in the incorrect time. A software system doesn’t need complete flexibility, but it does need to maintain options at the points where change is likely to occur.

5. Deliver Fast: it refers to companies can deliver faster than customers can change their minds. To achieve that you should focus on 2 main practices:

– develop your product driving down cycle time (short iterations), with small batches of requirements and fewer things-in-process, so at the end of each iteration, you can have a rapidly feedback from your customers and decide how to continue;

– have a fast-moving self-directed development team with excellent reflexes and a disciplined, stop-the-line culture.

You can’t sustain high speed, unless you build quality in.

6. Respect People (aka Engage Everyone or Empower the team): Respect means that instead of telling people what to do and how to do it, teams are given general plans and reasonable goals, and are trusted to self-organize to meet the goals (semi-autonomous teams). Engaged, motivated, thinking people with proper training, coaching and assistance, are the basis of competitive advantage in today’s economy.

7. Improve the System (aka See/Optimize the whole): it refers to improve and control your entire value stream – from customer request to deployed software – instead of just optimize part of it (sub-optimization). One commonly practice used to optimize your system is the use of metrics, but the same concept applies: when a measurement system has too many metrics the real goal of the effort gets lost. The solution is to “Measure UP” – find a higher-level measurement that will drive the right results for the lower level metrics and establish a basis for making trade-offs.

CONCLUSION

These principles are universal guiding ideas, the application of them into a software development company requires analysis, interpretation, and an exhaustive work to translate them into appropriate practices that can be apply to a particular environment.

The more you learn about Lean, the more you will realize how much value it has when applying to software development projects. And always remember these: rapid delivery, high quality, and low cost are fully compatible; learn from experiences and never stop getting better!

REFERENCES
– Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck – 2003

– Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck – 2006

NOTE

Originally, I wrote this article for Tim McMahon’s A Lean Journey blog.

Image provided by: Stuart Miles – FreeDigitalPhotos.net