When Agile Needs to Inspect Itself

-

 There is a pattern I have seen repeat across organizations of different sizes and industries. Teams adopt an Agile framework, populate their calendars with the right ceremonies, use the right vocabulary in standups, and then wonder why delivery feels just as slow and friction-filled as before. This is Agile Theatre: the performance of methodology without the substance of it. SAFe is perhaps the most visible example, a framework so dense with alignment meetings and coordination layers that the overhead of running it can quietly consume the productivity gains it was supposed to create. I have been thinking about this problem lately, and two frameworks have helped me sharpen my thinking: Agile² and DORA.

The piece "Agile²" makes an argument worth sitting with. Agile, in its original form, was a correction to a specific failure mode: process worship. The Agile Manifesto pushed back against the idea that following a detailed plan was the same as delivering value. The uncomfortable irony is that many teams today have rebuilt that same failure mode with new vocabulary. Scrum ceremonies, SAFe PI planning, story point velocity tracking -- these can become the thing teams optimize for, rather than the actual delivery of working software.

Agile² is the discipline of applying Agile's own logic to Agile itself. Every ceremony, every artifact, every process gets subjected to a single question: does this practice increase the rate at which we deliver correct, valuable software? If the answer is no, it gets cut. The framework commitments that follow from this are notably concrete. Velocity must be defined in measurable terms. Ownership must stay close to the work. Every ceremony should be treated as an experiment with a sunset clause. And "because Scrum says so" is never an acceptable justification for anything. That last one deserves to be posted on the wall of every planning room.

DORA metrics give that single question some teeth. Developed by the DevOps Research and Assessment program, the four key metrics are Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Restore. Together they shift the measurement conversation away from outputs like story points and velocity, and toward outcomes: how fast does working software reach production, how often does it break, and how quickly does the team recover when it does. That shift in focus is significant. You can hit every sprint goal and still have a slow, fragile delivery pipeline. DORA makes that visible.

What I find valuable about pairing these two frameworks is how well they fit together philosophically. Agile² supplies the discipline of questioning every process. DORA supplies the objective data to make that questioning honest. Without measurement, process improvement is just opinion. Without a willingness to question your processes, metrics become another form of theatre. Used together, they push teams toward something the original Manifesto was actually after: continuous, real improvement grounded in outcomes rather than ceremonies.

The deeper lesson here is not about any specific framework. It is about the habit of turning Agile's own tools back on Agile. Inspect and adapt is supposed to apply to how you work, not just to what you build. If your retrospectives never result in a ceremony being eliminated, if your velocity number is stable but your delivery confidence is not, it may be time to ask the hard question. Does this practice make us faster, or does it just make us feel organized? That question, asked honestly and regularly, is what separates genuine agility from the performance of it.

Popular posts from this blog

The Dual Faces of Technology: Enhancing and Replacing Jobs

-
Image
Automation has been on my mind a lot lately, more immediately due to a book I read , but also because of the looming reality of artificial intelligence. To understand what's involved, making the distinction between replacing technologies and enabling technologies is crucial. As we traverse the timeline of the 20th century, we observe how each type of technology has distinctly influenced employment. Automated technologies have transformed industries by replacing manual labor with machines. Consider the automated switchboards introduced in the early 20th century. Previously, telephone operators manually connected calls using physical connectors on a switchboard. With the advent of automated switchboards in the 1920s and 1930s, many of these jobs were eliminated as calls were routed through electromechanical systems. Similarly, in agriculture, the introduction of mechanical harvesters like the combine harvester in the 1930s drastically reduced the need for manual labor. These machine...
Read more

The Technology Trap: Capital, Labor and Power in the Age of Automation (Book Review)

-
Image
In his compelling book, " The Technology Trap: Capital, Labor, and Power in the Age of Automation ," Carl Benedikt Frey offers a sweeping examination of the historical and ongoing impact of mechanization and automation on society. Starting with the onset of the first Industrial Revolution, Frey deftly navigates through the evolution of technology up to the modern age of artificial intelligence, presenting a nuanced view of how technological innovations have reshaped labor markets and power dynamics. Frey categorizes technological innovations into two types: enabling technologies, like the typewriter, which enhance worker productivity without displacing the labor force, and replacing technologies, such as robotic machinery in factories, which eliminate certain job roles altogether. This distinction forms the backbone of Frey’s analysis, as he explores the varying implications of each type of technology on different segments of the workforce. The book traces a historical patter...
Read more

Deputy Product Owners

-
Image
"The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner." - The Scrum Guide There are a lot of ways in which my approach to Scrum differs from what's in the official guide, and since that document refers to Scrum as 'immutable,' let's just call what I do 'Notscrum™.' In Scrum, there is only one product owner per team. That person is the sole person responsible for the product backlog, and the person who advocates for the work to be done. In Notscrum there is one product owner, but there can be multiple deputy product owners. Here's how it works. When my program at Viacom was first forming I met with the then-director of the Library & Archive group and learned that while he set the priorities on work done, the archivists were organized in three distinct areas with a team lead ...
Read more