It's only really fair to think of code which is tied to features or bugfixes which haven't been released yet. The reason why inventory is a problem in Lean is b

It's only really fair to think of code which is tied to features or bugfixes which haven't been released yet. The reason why inventory is a problem in Lean is because it represents spend that hasn't been repaid with revenue, once you ship the code then it's shipped. Within the Lean model, I think it makes more sense to think of code as something that "weighs down" the different stations in the factory, making them less efficient, like unmaintained workstations in a factory that slowly break down. If you have a station in your software factory representing API changes, then whether or not you have a pile of half-completed work waiting for API changes has little to do with how quickly you can make changes to the API - that's determined by how many changes you've made before. It's much easier to delete code if you're allowed to delete features. And it's much easier to delete features if you have a clear deprecation and EOL policy, an easy way for customers to determine if they're affected, and simple means of migration.