7 wastes of software development
| 7 wastes of software development |
|---|
| See also |
7 wastes of software development are the modified version of 7 wastes of lean adjusted to requirements of Lean software development. They were described by M. Poppendieck and T. Poppendieck.
7 wastes
1. Work done partially
- The software that was never finished has tendency to become obsolete.
- Partially created code cannot be tested, so we don't know whether it will work.
- It cannot be also checked whether it will solve the business problem.
- Until the work is done, the value isn't created - there are costs, but no added value
- Partially done work increases risk and waste
2. Extra processes
If the process works smooth, some managers would like to add some paperwork to document it. This destroys process. Some documentation is required. Knowledge should be collected as lessons learned. But it cannot compete for resources with creating value for the customer.
The paperwork should be done only if someone needs it to perform tasks creating value for the customer. Just because the paperwork is required doesn't mean it adds value.
3. Extra features
Adding features just in case increases risk, makes software more complex, and what's the most important: doesn't creates value for customer, or at least customer won't pay for it. Adding extra feature is only beginning of the waste. The feature has to be tracked, compiled, integrated, tested.
The extra code may be nice, but is customer really needs it, or it's just ego of programmer?
4. Task switching
Workers that are in many projects in one time have to switch tasks. This limits their performance. There are methods like Single Minute Exchange of Project (see: article on Lean product development), but the performance still is lower than in one project. On the other side, if the worker time isn't used fully in one project the performance is lower anyway, so why to bother.
There should be decisions made by managers and team leaders. In some cases it is better for the project to have workers in one project only. Sometimes it's better for the company to share employees between projects.
5. Waiting
Delays happen on every stage of the project: starting, staffing, documenting requirements, reviews, approvals, testing, deployment, etc. Time cannot be managed - it flows with constant speed. You can only organize work to utilise it fully.
6. Motion
Any motion requires resources. If the team works in many places and has to meet every week, the costs of transportation quickly become huge. But motion is not only there. Other examples of waste are: not accessible customer to discuss features, not complete documentation, etc.
7. Defects
Defects are the most obvious waste, however many of them aren't notices. Programmers can remove them before someone finds it. But the time was lost. But the faster the problem will be identified, the smaller the waste. Detection should be as soon as possible.
Discussion about 8th waste
The authors added originally also the 8th waste - management activities. They claim that management activities don't add value to a product and therefore are waste. Well, if so, who is responsible for implementing lean software development?
It doesn't matter whether decisions are made by "manager" or "employee" or better say "knowledge worker". The fact is decision making is managerial activity. We can imagine company without managers, but not without management.
References
- Poppendieck M., Popendieck T. (2003), Lean Software Development: An Agile Toolkit, Addison-Wesley Professional
- Presentation of Lean Software Development tools and approaches (PDF)
Author: Slawomir Wawak
