In this series on the Seven Wastes, we’ll attempt to highlight the 7 wastes in various industries and disciplines. Today, we’ll consider The Seven Wastes of Software Development.
[contentblock id=31]
If the customer were to peer over your shoulder, what would they have you stop doing?
In Lean Thinking, Waste is activity that adds cost but not value – from the customer’s perspective
Given that, here are the 7 Wastes of Software Engineering:
Transportation
- Handoffs – Movement of product that does not add value.
Inventory
- Requirements – Product Requirements Documents (PRD), Story Cards – more material information than the customer needs
- Completed code, but not checked-in
- Completed code, but not documented
- Untested code
- Code in staging environment, but not in production environment
- Code with overwhelming amount of comments /*comments*/
Motion
- Task-Switching – Bodily or mental motion that does not add value
- A evil-twin of Task-Switching is Multi-Tasking
Waiting
- Delay – Idle time when people, material, information, or equipment is not ready
- Waiting for project approval
- Waiting for resources
- Waiting for change approval process
- Waiting for product management or requirements
Overprocessing
- Extra Steps or Effort – effort that does not add value from the customer’s perspective
- Having to relearn what a function, class, or piece of code does
- Having to refactor a piece of code when it already meets requirements
Overproduction
- More Stuff – Producing more than the customer needs or wants
- Featuritis or Feature Bloat: more features than the customer needs, wants, or asked for
- Wrong Thing – Building something a customer doesn’t want or does not use
Defects
- Bugs – errors, rework, mistakes, or is missing something necessary
It’s Your Turn
What other examples do you have? Do you agree or disagree?
Great post, as always.
How about :
– No automation of recurring, low-value, low-skill tasks (data extracts, etc). I guess that qualifies for “Extra effort”.
– Spending on hardware to fix design/code issues (“servers & storage are cheaper than good developers”)
– Inertia (not quite the same as “Waiting”) : “things are different here”, “we’ve always worked like this”, etc.
– Death by meetings…
I could add a lot more 🙂
Most of these are very accurate.
However, some of these can’t be avoided especially for mature companies. They sort of fall into the category of “If you do things perfectly then you don’t need CM Processes, you won’t have Bugs, etc.”
Waiting for Change Management Approval for instance is something that if you do not get proper CM review and approval you risk releasing something that has no value to the customer but has negative value and wastes more time fixing up the deployment. It actually adds more risk that you will have introduced a misconfiguration, network error, bug, etc.
In terms of requirements, it is often the case the Engineering needs far more information than the customer needs. Customers typically only focus on nominal use-cases. It’s rare that they ever consider negative use-cases and how those should be dealt with. Customers also typically focus only on functional use cases (what they can see) and rarely on the non-functional use cases (i.e. performance, availability, etc.).
I agree with Julian very much on Automation, Inertia and Death by Meetings. Meetings with no specific agenda and goal are the single biggest waste of time and money I see.
At your next meeting just look around the room, add up everyone’s hourly rate and ask yourself if you’d really pay that much for the outcome of the meeting. This is especially true when nobody had the opportunity to prepare because there was no agenda and no objective. At the end, you will generally get “Okay, let’s have another meeting in the future now that everyone understands what we were supposed to do at this one.”
Ask yourself, would I really pay this much for this outcome? If the customer is at the meeting, what do they think of our prep and did we just waste their time?