Detecting Agile BS: Lessons from the Department of Defense

Published on
5 minute read

In the realm of Agile, there’s a common trap that many organizations fall into: the belief that implementing Agile development practices is enough to achieve true agility. However, as the Department of Defense’s “Detecting Agile BS” guide reveals, Agile development alone isn’t sufficient if the rest of the system operates in a traditional, bureaucratic manner. This blog post delves into the insights provided by the guide, exploring why a fully Agile ecosystem is essential and offering practical advice for organizations striving to eliminate Agile BS.

The Pitfall of Partial Agility

Why Agile Development Isn’t Enough

One of the most significant challenges organizations face is the disconnect between Agile programming teams and the broader, often linear, deployment processes. Imagine this scenario: your development team operates in an Agile manner, continuously delivering code in short sprints. But once that code is ready for deployment, it hits a wall of bureaucratic hurdles, slowing down the entire process.

In such cases, the Agile development team’s efforts are undermined by the organization’s inability to support continuous delivery. This is a common issue, and if you’re working in an environment where your team can’t deliver continuously to production without human intervention, it’s a clear sign that the full ecosystem of your project isn’t Agile.

The Importance of Continuous Delivery

Continuous delivery is a hallmark of true Agile practices. It’s the ability to deploy code to production quickly and reliably without manual steps. But how many organizations truly achieve this? The reality is that many still struggle with manual processes, which can introduce delays and reduce the overall agility of the team.

Here’s a quick self-check:

  • Is your team able to continuously deliver to production?

  • Are there no bureaucratic barriers between code submission and deployment?

  • Is the quality of your product high enough that additional checks, like User Acceptance Testing (UAT), are unnecessary?

If the answer to any of these questions is “no,” then your organization may not be as Agile as it thinks.

Engineering Excellence and Continuous Delivery

Why Quality Matters More Than Ever

A critical aspect of achieving a fully Agile ecosystem is prioritizing quality at every stage of the development process. I once worked with a team responsible for developing firmware for pacemakers—a product where quality literally means life or death. Their software had to pass rigorous external tests and validations, but they expected every test to succeed because they had built quality into every step of their process.

While most of us aren’t developing life-saving devices, the principle remains the same: high-quality products reduce the need for extensive manual checks and validations. If your organization still relies heavily on UAT, it might indicate that your product’s quality isn’t meeting the expected standards.

The Role of User Acceptance Testing (UAT)

User Acceptance Testing is often seen as a necessary step in the deployment process, but it shouldn’t be. If your product consistently passes UAT without issues, it might be time to question its value. In such cases, UAT becomes a cost center rather than a value-add, and eliminating it could save time and resources.

To achieve this:

  • Bake quality into your definition of done. Ensure that every feature meets high standards before it’s considered complete.

  • Integrate automated testing into your development process. Automated tests can catch issues early, reducing the need for manual UAT.

  • Strive for a seamless deployment pipeline. The goal is to ship to production continuously without manual intervention.

The Six-Question Litmus Test

Assessing Your Organization’s Agility

The Department of Defense’s guide provides a six-question litmus test to help organizations assess their level of agility. While the guide’s origin may surprise some, given the traditional nature of the Department of Defense, its insights are invaluable.

Here are the six questions you should ask yourself:

  1. Are your teams able to continuously deliver to production?

  2. Is there no human intervention required between code submission and deployment?

  3. Do you have automated checks and validations in place?

  4. Is UAT unnecessary because your product quality is consistently high?

  5. Have you minimized bureaucratic barriers in your deployment process?

  6. Are your Agile practices truly integrated across the entire ecosystem?

If you can’t answer “yes” to all these questions, it’s a sign that your organization still has work to do. But don’t be discouraged—this isn’t about pointing fingers or declaring failure. Instead, it’s an opportunity for self-reflection and continuous improvement.

A Path Toward True Agility

To move closer to true agility, consider the following steps:

  • Evaluate your deployment process. Identify any bureaucratic steps that could be streamlined or eliminated.

  • Invest in automated testing. Automated tests are crucial for maintaining high quality without relying on manual checks.

  • Foster a culture of continuous improvement. Encourage your teams to regularly assess and refine their processes to eliminate Agile BS.

Conclusion: Striving for True Agility

Achieving true agility requires more than just adopting Agile development practices—it’s about creating an ecosystem where every aspect of the process supports continuous delivery and high-quality outputs. The Department of Defense’s “Detecting Agile BS” guide offers a valuable framework for assessing your organization’s agility and identifying areas for improvement.

Remember, the journey to true agility is ongoing. By regularly evaluating your processes, prioritizing quality, and eliminating unnecessary bureaucratic steps, your organization can move closer to a fully Agile ecosystem—one where Agile BS has no place.


Key Takeaways:

  • Agile development alone isn’t enough; the entire ecosystem must support agility.

  • Continuous delivery and high-quality outputs are essential for true agility.

  • Regularly assess your processes using the six-question litmus test to identify areas for improvement.

Pro Tip: If you find that your organization isn’t fully Agile yet, don’t worry. Use it as a chance to reflect, adapt, and continuously improve. After all, that’s what agility is all about! 🚀

The final question for asking leadership within the organization is going to be a stickler. I see this in organization after organization being a difficult problem to discuss, and that is: is the full ecosystem of your project agile programming teams followed by linear bureaucratic deployment a failure? How many of you out there listening to this are working within organizations where you’re able to continuously deliver to production, where there is no human intervention required between the developer submitting the pull request, being approved, and getting all the way to production? How many of you work in that sort of environment where there are no bureaucratic things in between you and production? There may be tests between you and production; it may take time for your product to roll out because it has to go through a set of automated, standardized checks, perhaps compliance things.

I do work with a team that makes firmware for pacemakers, and you better believe they have a lot of compliance they have to meet. Their software, after they create their usable working item to ship, needs to run a gauntlet of external tests and validations, but they expect all of them to pass because they’ve done all the things to ensure that it does. So, it’s unusual for anything in that story to be a failure that they have to have manual processes, right? That little bit of bureaucracy in their way, but only to protect people’s lives. It’s the absolute minimum needed to ensure that we protect people’s lives.

However, for most systems that we work with, we want to be delivering high enough quality to our business that we’re able to remove a lot of those traditional bureaucratic points in that story. For example, user acceptance testing. If you have user acceptance testing in your business, it’s because it’s a value centre. If your customer insists on doing user acceptance testing when you give them product, it’s because it’s a value centre for them. You give them product, and they find problems. Therefore, UAT has added value for them. Why are they finding those problems? They’re finding those problems because the quality of the product that you’re giving them is not high enough to pass the bar that they’re expecting and that they’re paying you for.

If it was high enough, then their UAT wouldn’t find anything and would become a cost centre, and then that’s a conversation about eliminating cost. If it’s never finding an issue with your product, it’s of no value to them to do it because your product is high enough quality. You should all be striving to have a high enough quality product that you don’t need additional checks and validations. If you need to have something that somebody else wants to see as part of your process, bake it into your definition of done. Bake it into the way you build software so quality is so high you don’t even have to worry about it. You can continuously ship to production.

If your answer to any one of these questions, or the answer of your business to any one of these questions, is no, we’re not doing that, then you would probably—I probably wouldn’t consider that you’re already in the agile space, right? You’re not already agile. You might be working towards it, and you might have put in loads of effort, but unless you can mark every single one of these six questions as yes, we do this, this is how things work here, then we’re still lacking. We’re still trying. We’re still working towards being agile.

Now, this is just a litmus test dreamed up by the US Department of Defense, but they are probably the least likely place for you to expect something with this high a bar to have come from. I’m not going to go into a team and work with a team or a company, and if they’re not doing these things, then I’m going to say, “Well, you guys suck, you’re not agile,” because you’re not doing this. That’s not how we work towards success.

But I think it’s hugely valuable from the perspective of self-reflection for you all to think about the processes and practices in your organization. How many of these six questions are you able to achieve, and what could you do to make it a little bit easier for the teams, for the people doing the work, to work towards this idea of not being agile BS?

People and Process Product Delivery Business Agility Value Delivery Agile Philosophy Agile Strategy Software Development Operational Practices Software Developers Pragmatic Thinking

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

Brandes Investment Partners L.P. Logo
Xceptor - Process and Data Automation Logo
MacDonald Humfrey (Automation) Ltd. Logo
Milliman Logo
Bistech Logo
Alignment Healthcare Logo

CR2

Boeing Logo
Genus Breeding Ltd Logo
Kongsberg Maritime Logo
Ericson Logo
Hubtel Ghana Logo
Teleplan Logo

NIT A/S

SuperControl Logo
Slaughter and May Logo
Healthgrades Logo
Epic Games Logo
Washington Department of Enterprise Services Logo
Royal Air Force Logo
Department of Work and Pensions (UK) Logo
Ghana Police Service Logo
New Hampshire Supreme Court Logo
Nottingham County Council Logo
Higher Education Statistics Agency Logo
Deliotte Logo
Boxit Document Solutions Logo
Big Data for Humans Logo
Teleplan Logo

CR2