https://nkdagility.com/resources/O6rYL3EDUxM copied to clipboard!

Scrum Leadership

tech·nic·al·ly agile

Detecting Agile BS: Lessons from the US Department of Defense

Is your company truly Agile? 🤔 Discover a 6-question test inspired by the U.S. Department of Defense to assess and enhance your Agile practices!

Published on 28 June 2024

Written by Martin Hinshelwood

6 minute read

https://nkdagility.com/resources/O6rYL3EDUxM

The concept of Agile has taken the business world by storm, with organizations everywhere claiming to have adopted Agile methodologies. But are they truly practicing Agile, or is it just Agile in name only? One of the most eye-opening resources on this topic comes from an unexpected source—the US Department of Defense (DoD). Their guide, titled “Detecting Agile BS,” was created to help procurement officers determine whether vendors were genuinely Agile or merely paying lip service to the methodology. This guide raises important questions that every organization claiming to be Agile should ask itself.

The Rise of Agile in Procurement

In 2013, the US Department of Defense made a significant shift in their procurement terms, requiring iterative and incremental delivery of products and systems. This was a bold move, intended to align their processes with Agile principles. However, this shift led to an immediate response from vendors: suddenly, everyone was “Agile.” The problem? Many of these vendors were far from practicing true Agile. They declared themselves Agile overnight, without making the necessary changes to their processes, culture, or mindset.

Are Organizations Really Agile?

This phenomenon isn’t limited to defense contractors. As someone who has worked with various organizations over the years, I’ve seen this pattern repeated time and again. Many organizations claim to be Agile, but in reality, they are not. It’s a harsh truth, but one that needs to be addressed if we are to improve and truly embrace the Agile way of working.

The Six Questions to Detect Agile BS

The DoD’s guide provides six crucial questions that serve as a litmus test to determine whether an organization is genuinely Agile. These questions are designed to cut through the noise and get to the heart of whether an organization is delivering on the promises of Agile. Let’s dive into each of these questions and why they matter.

Question 1: Are Teams Delivering Working Software to Real Users Every Iteration?

This is the first and arguably most important question. Are your teams delivering working software to at least some subset of users every iteration, including the first? And are they gathering feedback from those users?

Continuous Delivery: True Agile teams deliver working software frequently—every iteration. This means no User Acceptance Testing (UAT) or test environments—real, live production users.
User Feedback: Gathering feedback from these users is critical. Without it, you’re flying blind, unable to adapt to user needs and preferences.

Challenges and Benefits of Continuous Delivery

Achieving this level of agility is not easy. Many teams struggle to create working products in every iteration, let alone deliver them to production. However, the benefits are undeniable. Organizations that adopt continuous delivery see significant improvements in product quality and customer engagement.

Why it’s worth it:

Higher product quality.
Greater customer engagement.
Once you achieve continuous delivery, no organization has ever chosen to go back.

However, reaching this stage requires significant investment in both technical skills and leadership commitment.

Question 2: Are Teams Regularly Releasing to Production?

This question complements the first. It’s not enough to deliver working software to users; you must also release it to production regularly. The Agile Manifesto emphasizes the importance of delivering frequently, with a preference for shorter timeframes.

Scrum Guidelines: The Scrum Guide recommends releasing to production at least every 30 days. If your organization isn’t doing this, you’re not fully embracing Agile.
Investment Required: Achieving this requires changes to your business practices and a commitment to continuous improvement.

Question 3: Are Teams Adapting Based on Feedback?

Agile is all about adaptability. Are your teams regularly adjusting their approach based on the feedback they receive? This requires a culture of openness, where feedback is valued and acted upon.

Question 4: Is There a Clear Product Vision?

Without a clear product vision, it’s impossible to prioritize effectively. Agile teams need to have a shared understanding of what they are trying to achieve and why. This vision guides their work and helps them make decisions that align with the organization’s goals.

Question 5: Are Teams Empowered to Make Decisions?

Empowerment is a core principle of Agile. Are your teams empowered to make decisions about their work? Or are they constantly seeking approval from higher-ups? True Agile teams have the autonomy to make decisions that impact their work, allowing them to move quickly and respond to changes.

Question 6: Is There a Culture of Continuous Improvement?

Finally, Agile is about continuous improvement. Is your organization committed to regularly reviewing and improving its processes? This requires a mindset of experimentation and learning, where teams are encouraged to try new things and learn from their experiences.

Why Honesty About Your Agile Maturity Matters

If your organization can’t honestly answer “yes” to each of these six questions, then it’s time for some serious self-reflection. Claiming to be Agile without truly practicing it does more harm than good. It creates a false sense of security and prevents real change from happening.

Self-Reflection as a Path to Growth

It’s important to approach this process with humility and a genuine desire to improve. No organization is perfect, and Agile is a journey, not a destination. Use these questions as a tool for self-assessment, and don’t be afraid to acknowledge where you fall short. Only by being honest about your current state can you begin to make meaningful progress.

Practical Steps to Improve Your Agility

Start small: Don’t try to change everything at once. Focus on one or two areas where you can make a real impact.
Invest in training: Equip your teams with the skills they need to succeed in an Agile environment.
Foster a culture of feedback: Encourage open communication and make it safe for team members to share their thoughts and ideas.

Conclusion: Embrace the Challenge

Adopting true Agile practices is challenging, but the rewards are well worth the effort. The US Department of Defense’s guide to detecting Agile BS is a powerful tool for any organization looking to assess and improve its Agile maturity. By asking the right questions and being honest about where you stand, you can begin to make the changes necessary to truly embrace Agile.

Remember, Agile is not just a set of practices—it’s a mindset. It requires a commitment to continuous improvement, a willingness to adapt, and the courage to be honest about where you are on your Agile journey. So, take the time to reflect on these questions, and use them as a guide to help your organization grow and thrive in the world of Agile.

🎯 Pro tip: Regularly revisit these questions as your organization evolves. Agile is a journey, and these questions can help you stay on the right path.
🚀 Take action: Start by focusing on one area where you can improve, and build momentum from there.

Agile isn’t easy, but with the right mindset and approach, it’s achievable. And once you get there, you’ll never want to go back.

One of the really interesting articles that I’ve seen in the last few years has been from a little organization that you might have heard of called the US Department of Defense. They released an article called the DIB guide to detecting Agile BS. This was sent out to all of their procurement officers worldwide so that they could tell whether the vendors that they were hiring, because they’re the procurement officers, were actually Agile or were just making it up.

Because one of the problems that they ran into was right at the start, they realized that when they switched over to Agile procurement terms back in 2013, the US Department of Defense updated their main procurement terms to require iterative and incremental delivery of any product or system. When they moved to that model, their vendors just all immediately declared themselves to be Agile. The next day, “Oh yeah, we’re Agile, we do it in an Agile way.” But most of them were lying.

Something that I found working with organizations, and I’m going to use the word that’s quite dramatic, most organizations that say they’re doing Agile are also lying. I’ve been dramatic, but they kind of are. The detecting Agile BS article came up with a whole bunch of questions. It’s totally worth going reading it, but there are six main questions which I think are the most important pieces of the story.

This was the questions to leadership within the organization, so I’d like you to think about these questions from your perspective within your organization. If you asked your leadership if this is true across the board in your organization, is it true?

So there are six questions. The first one is: Are teams delivering working software to at least some subset of users every iteration, including the first, and gathering feedback? Think about that. Every single iteration, you should be delivering working product to real users, not UAT, not a test environment, real production users every iteration, including the first.

Now that’s really hard. Lots of teams struggle with creating working product, with getting that working product out the door, and even more like gathering feedback. That’s almost as rare as delivering working product. So what this is effectively saying is that if you as a team or you’re part of the organization is unable to deliver working software to production on a regular cadence, you’re probably not being very Agile.

Ideally, you want to be delivering on a very regular cadence. The Agile Manifesto would talk about from a couple of weeks to a couple of months, I think is the phrasing it uses, with a preference to the shorter time scale. So you probably shouldn’t go two months without shipping to production.

For the Scrum Guide, it talks about no more than every 30 days, so it puts a hard one month figure on that 30 days. That can be difficult for organizations. There are lots of organizations out there that have made this change. No organization that has made this change towards continuous delivery to production has gone back and decided not to do it anymore.

Once you get there, the level of quality that you need in your product, the engagement you get with your customers, these are all things that are much, much, much higher once you get there, and nobody wants to go back. But getting there is difficult. It takes time, investment in skills for your engineering teams, in skills for leadership, in changes to your business practices to make that in any way viable.

But it is absolutely worth it, and even the US Department of Defense requires that their vendors are able to deliver working software to real users every iteration, including the first. 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.

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?

Agile Values and Principles Working Software Agile Strategy Agile Philosophy Continuous Improvement Agile Project Management Agile Transformation Software Development Pragmatic Thinking People and Process

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.

CR2