Software teams spend millions building features that deliver minimal value while critical security vulnerabilities rise. Security is often viewed as a blocker. Slowing down the speed of delivery. Yet, Pareto’s Principle, and my experience suggests , at least 80% of development effort creates features that drive little user value.
Your CI/CD pipeline might be humming at record speed, but you’re running an assembly line that churns out inventory nobody wants.
The Lean Manufacturing Lie
“The Phoenix Project” Gene Kim, Kevin Behr, and George Spafford) and “The Unicorn Project,” (Gene Kim), describe a great success of leveraging Kanban and Lean Manufacturing principles of the software industry. The challenge is, in doing so they have left software development teams misapplying their practices.
Here’s what they missed: Lean Manufacturing works because of three fundamental assumptions that don’t exist in software.
First: Predictable Production Time Toyota knows how long it takes to build a Camry. Software teams sprint toward arbitrary deadlines, pretending two-week cycles create predictability. They don’t.
Second: Limited Product Changes Toyota changes car models once per year. Your product changes daily, sometimes hourly. Every sprint delivers essentially new software. The stories that fill those two week sprints may not change, but once those stories are built they are done and not rebuilt. Each story is unique, even if implementations for similar stories can be repeated by different teams with different skill sets.
Third: Known Demand Toyota has sales data and market research. You have user stories and best guesses. Given the amount of any specific software product which gets limited to no real value from its implementation, it’s questionable whether the real demand is known. User interviews and A/B testing can help trim this down, but the real problem is there’s still only so much a user is going to do. The bigger the software gets, the less useable it becomes.
Architecture and Developer Time: The Real Constraints
“The Phoenix Project” and “The Unicorn Project” focus on the theory of constraints raised in “The Goal” (Eliyahu M Goldratt and Jeff Cox). The slowest part of any system determines overall pace. In “The Goal,” Alex discovers this on a Boy Scout hike where the slowest scout sets the troop’s speed. In his factory, Alex discovers two machines in the line which take time to process their parts.
The challenge with the software development life cycle is that the build and deployment process are only part of manufacturing process. And in “The Unicorn Project”, they actively talk about the time that automated tests take to run. They don’t stop the tests, they find strategies to increase throughput.
It was learned in “The Goal” that Alex adds quality checks to before and after the slowest point. They don’t eliminate final quality control checks. They add checks. This means that the creation of any given unit takes longer to create than it did to create. The line, however, is able to deliver more effectively because of how time is used in that cycle.
Every low-value feature represents:
- Code that needs security maintenance
- Attack surface that needs monitoring
- Dependencies that need updating
- Complexity that slows future development
The Real Waste Pipeline
Alex learned that local efficiencies didn’t matter. They could end up costing the company more money because the cost of inventory sitting was a negative impact. In software, the impact is much more subtle. The cost isn’t in needing larger warehouses. The cost is in the support, maintenence and continued scanning of the old code that is barely used.
While you celebrate another deployment, consider what you’re actually delivering:
- Feature Bloat: Experience and Pareto’s Principle suggest most software features deliver minimal value
- Security Debt: 22,254 new vulnerabilities disclosed by mid-2024—a 30% increase from 2023 (https://insight.scmagazineuk.com/number-of-reported-vulnerabilities-increases-in-2024)
- Technical Debt: Outdated libraries, unpatched systems, and architectural shortcuts
- Patch Failures: 60% of data breaches caused by failure to apply available patches (https://www.darkreading.com/vulnerabilities-threats/unpatched-vulnerabilities-the-source-of-most-data-breaches)
Your throughput metric ignores the most expensive waste: building things that create liability instead of value.
The Real Throughput Question
The question isn’t “How fast can we ship features?”
The question is “How fast can we ship high value and high quality features while eliminating waste?”
Lean Manufacturing succeeded by eliminating excess inventory. Your excess inventory is low-value features carrying security risk.
Your Next Sprint Planning
Before your next sprint planning, ask these questions:
- Usage Evidence: What data proves users want this feature?
- Security Impact: What attack surface does this feature create?
- Maintenance Cost: What’s the long-term security and maintenance burden?
- Value Measurement: How will we know if this feature succeeds?
If you can’t answer these questions with data, you’re not implementing Lean Manufacturing—you’re implementing Feature Factory Manufacturing.
The Choice
You can keep optimizing your deployment pipeline while building an inventory of low-value, vulnerable features.
Or you can apply real Lean principles: eliminate waste, focus on customer value, and treat security as a quality constraint.
Your throughput metrics look impressive. Your security posture tells the real story.
The choice is yours. Choose wisely. Your customers’ data depends on it.