Eliminating waste is a key concept in lean process thinking. Waste reduction is often seen as a way of increasing productivity. Since lean is the grandfather of agile we can perhaps borrow this key concept and apply it to software engineering.
Through identification and elimination of waste in our software teams we can build our products efficiently, potentially reducing costs but also improving time to market.
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.
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, 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.
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.
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.
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.
The principles of Lean work well in both manufacturing and service industries, and the ideas on eliminating waste are important to keep in mind when developing software. It may require pushing back against management in order to implement Lean processes, but that’s a battle worthy of participation.