You Can't be agile with Agile™ Process Alone

Agile approaches were a big improvement over old-school waterfall practices. They introduced short iterations, rapid feedback loops, and more transparency around tasks. However, several issues arise when Agile™ is seen as a silver bullet:

• Metrics Can Be Gamed: “Velocity” increases if you just split tasks into smaller tickets.

• Subjective Measures: Story points and burn-down charts don’t always correlate to actual business impact.

• Short-Term Focus: Driving only user stories without tending to deeper architectural needs can accelerate “technical debt.”

We’ve seen teams with impeccable Scrum discipline yet still struggling to compile or release on time, simply because their system’s technical architecture was unhealthy. In fact, many “Agile™” organizations over-index on daily ceremonies while ignoring the underlying code structure.

Technical Health: The Overlooked Key to Real Agility

A robust codebase with high cohesion and loose coupling supports true adaptation:

• You can change one module without breaking another.

• Smaller, well-defined components are easier for developers to understand and modify.

• Good APIs hide complexity so that fixes remain localized.

• Flexible architecture makes it straightforward to replace or remove outdated components.

As researchers at MIT, Harvard Business School, and Silverthread we have analyzed thousands of commercial, government, and open-source systems, showing that technical health is often the hidden driver of cost, speed, and ultimately, project success:

• Feature Development Time: We’ve seen projects where a single feature takes 150 days instead of 12, due to entangled code.

• Security Patches: Healthy architectures can patch in hours; unhealthy ones can take a year.

• Releases & Compilations: Some organizations deliver daily builds, while others can’t compile after three years of trying—Agile(™) certifications notwithstanding.

• Productivity Potential: Our analysis suggests the industry could deliver twice as many features annually if it systematically managed architecture quality (Sturtevant, IEEE).

  
  

Balancing Process Agility & Product Agility

Effective teams combine solid project management with robust technical architecture. Below is a snapshot of what you can measure and manage from both realms:

Agile Process	Technical Health
Velocity (Story Points)	Architecture: Modularity, Hierarchy, APIs, Cyclicality
Burn Down Charts / Sprint Progress	Architecture conformance
Sprint Commitments vs. Actuals	Code Duplication
Daily Stand-Ups / Retrospectives	Code quality / Complexity
Lead Time for Work Items	Automated Build & Test Coverage
Defect Rate Per Sprint	Security

Most organizations measure only the left column—process metrics—while ignoring the right column. This imbalance can mean you’re fast in a short sprint, but can’t pivot effectively for new requirements.

Proof Through Success Stories

This video game company went through 3 refactoring efforts. The third refactoring effort was successful, as could be seen in important technical health metrics. Immediately afterward, you can see a dramatic increase in the rate at which the firm could publish revenue generating games.

• A video game company quadrupled the number of new titles released (per year) after modularizing its game engine.

• Firefox nearly collapsed under complexity. A small group refactored critical layers, turning it into a flagship browser.

• A scientific computing company modernized a massive codebase and scaled from $750M to $2B in revenue by improving architecture and build infrastructure.

• A DoD program achieved 3x development productivity by identifying and fixing architectural flaws in four months.

• A robotics firm fended off competitors by “shrinking the tumors” in its code, enabling faster iteration on key features.

  
  

In each case, focusing on code and architecture—rather than just process—unlocked genuine agility and growth.

Measuring and Managing Technical Health with Silverthread

Silverthread’s CodeMRI® platform helps organizations:

• Assess structural complexity, duplication, and modular boundaries.

• Benchmark against thousands of systems.

• Model the ROI of modernization so non-technical executives see the tangible payoff.

• Guide targeted refactoring to minimize short-term disruption and maximize long-term agility.

This isn’t the heavyweight, top-down “architecture” approach that Agile™ sought to escape. It’s a lightweight, data-driven method to keep code healthy, flexible, and ready for rapid change.

Forward-thinking organizations—like certain USAF units—have already leveraged these insights, using quantitative architecture metrics to guide >$2B in modernization investments. They discovered that addressing technical health at scale dramatically reduced risk and improved delivery timelines.

Conclusion

If you rely solely on Agile™ processes, you might be speeding up a train that’s stuck on fixed rails. Or - being even more blunt - Walker Royce once told me that if you have Agile™ process but not an agile product - you just "make crap faster." True agility—the ability to change direction quickly and affordably—requires healthy, modular architecture as well. By balancing process and product agility, teams can adapt to shifting requirements, deploy new features faster, and achieve better ROI.

Silverthread can help you establish a technical health measurement and management program that complements your Agile™ methods. We bring clarity to the codebase so leaders—technical or not—can make rational decisions about modernization. If you want to be agile by any dictionary definition, invest in both process excellence and product agility.

About the Author

Dan Sturtevant is an experienced software architect who studied the cost of complexity at MIT and Harvard, is the CEO of Silverthread, and served for three years as a member of the Agile Alliance’s Technical Debt Working Group. He is the author of the IEEE paper “Modular Architectures Make You Agile in the Long Run.”