Measuring more but learning less
Driving continuous improvement and making better decisions is something I think everyone can agree on.
If individuals are being empowered to continually improve, they need metrics that allow them to learn and translate learning into better decisions over time.
We need metrics that inform decisions like:
Twenty-three years ago, the evolution from Waterfall to Agile wasn't about speed - it was about risk. Waterfall ignored risk, creating a brittle system where the accumulation of hidden failures evenually meant catastrophe. Early Agile promised something different: making failure survivable through small rapid learning cycles.
But somewhere along the way, we lost the plot. Today's obsession with DORA and other speed frameworks that focus on flow and cycle time echoes Frederick Taylor's "scientific management" - trying to optimize away the margin of error that enables learning.
A preoccupation with cycle frequency means we are now measuring more but learning less.
Risk increases when learning and decision making suffers. Here are a few examples from commercial aerospace:
? Pre-flight checklists and procedures exist to support judgment. After United 173 crashed in 1978 (running out of fuel while troubleshooting), aviation shifted from rigid checklists to CRM (Crew Resource Management) – empowering crews to adapt in real-time.
? When Chesley "Sully" Sullenberger landed on the Hudson, he abandoned every procedure and relied on his experience.
? The recent 737 MAX problems with the MCAS system shows what can happen when process becomes a substitute for learning rather than a foundation for it, the space for good decisions shrinks and catastrophic risk grows. The tragedy isn't just that processes failed, but that the adherence to process and superficial compliance actively prevented the learning and adaptation that could have prevented the failures and the fatalities.
Software needs to learn this same lesson: decision-first thinking:
领英推荐
? Critical decision-making should be made by humans, not processes.
? Testing shouldn't just prevent failures - it should make them less catastrophic
? Monitoring shouldn't just alert us to problems - it should give us room to respond
? Code reviews shouldn't just catch bugs - they should spread understanding
? Deployments shouldn't just ship features - they should create learning opportunities
In other words, Learning must improve Decision-Making in order to reduce Risk.
Instead of speed, sentiment, and reducing small failures, optimize for better decisions:
Like Toyota's andon cord, the power to stop, think, and adjust works to keep processes healthy and improving. When it is legitimate to abort processes it paradoxically makes processes more valuable - not as "guard rails", but as "green shoots" showing where learning and real progress is happening.
Agility in software development has a lot to re-learn. To improve, we must build systems that can fail safely, learn continuously, and adapt intelligently.
"Accelerating toward Catastrophe" was never the goal.
#EngineeringLeadership #Learning #SoftwareDevelopment #BusinessValue