The Toyota Production System (TPS, usually called "Lean" in the West) defines three sorts of difficulties, all of which apply to software development: Muri, Mura, and Muda. They're all worth thinking about.
Muri is long-term overburdening of the entire production system (e.g., too much work for the people at hand). That's not waste so much as creating a system incapapable of doing the work. To my mind, Muri also encompasses inappropriate organization architectures, where the management structure is fighting against working in effective—all too common in larger corporations, but you see it everywhere.
Mura is variation in the work to do. The biggest cause is usually random show-stopper bugs in the drop-everything-and-fix-this category. Variation can also happen at a macro level, for example, tax-related software that's used only once a year, so all the bugs surface over a couple of weeks rather than continuously throughout the year. In general, the more variation you have, the more buffering and slack time you need in your schedule to absorb it.
In the Muda category, TPS defines eight categories of waste (all of which apply to software). I use the acronym DOWNTIME to remember them:
Defects (of all sorts, but bugs and technical debt).
Overproduction (is related to Inventory. Producing software we can't sell—often because we're not validating products before we build them)
Waiting (all sorts of dependencies cause waiting, as do processes that mandate lots of meetings and the like).
unused taleNt (punishing people as "unproductive" instead of training them is a big one here.)
Transportation (when the work needs to move from one place to another—from product to dev or dev to test, for example—you have delays).
Inventory (work done that has not been released to customers. Money spent without a balancing revenue.)
Motion (too much process. too many meetings. Lots of motion, but no progress). *
Extra Processing (building more software than you need. futureproofing).
Of course, all this is just the tip of the waste iceberg, but it's a good start.
Brilliant interpretation of TPS in the software development space. I see all of this waste in the government contracting space. Sad part is contractors aren’t incentivized to fix it.
I like the acronym! And it will be easy for me to remember the N because what you did to it is the same as JetBrains did to the iNline refactoring shortcut :)