In September of 2019, Forbes published a provocative article entitled “How Fake Agile at DoD Risks National Security.” In the article, Forbes’ Senior Contributor Steve Denning explores how the Department of Defense is putting controls in place to attempt to root out the practice of using a traditional command and control approach in technology projects and labeling them as “Agile.” What the DoD has discovered is that without the expertise or experience required to employ effective Agile techniques, it has led to slowing down delivery and capabilities to users, or worse, force the delivery of capabilities that do not adequately meet the needs of the users.
In the excitement to bring Agile to the DoD, many service providers are claiming to use Agile when in fact, they are renaming old techniques to something that sounds like Agile but fails to deliver the value. Because what is at stake is so significant to their overall mission, the DoD has created a guide to help their teams “detect Agile BS.” The intention with the guide is to assist in making good decisions internally related to programs as well as assisting in the process of hiring DoD contractors.
For those of us at Steampunk that have lived this story many times over, we’re excited to see this kind of motivation by DoD to arm their teams with the intelligence they need to recognize the enemy. In this post we wanted to dig into the article a little further and introduce some of the techniques we use at Steampunk to not only detect the Agile BS, but get it back on track to reap the benefits that Agile can provide.
Government Identifying as Not-So-Agile
Throughout Denning’s article, the points he makes lead the reader on a journey to explain how modern DoD practices are changing to combat this challenge. There are now DoD guides that ask the questions necessary to determine whether an organization is truly practicing Agile or if they’re faking it. There are common patterns you can enter into a BS meter, and it’s not all that challenging to find those that may be well intended, but a lack of Agile knowledge has them falling back to traditional approaches to project management.
For those of us at Steampunk, this is a very refreshing change of pace. For years, we worked with government organizations that either didn’t want to embrace Agile at all, or when they did, is was good enough to take traditional processes and label them as Agile. Daily status meetings were scrums, monthly status reports were sprint reviews, and product owners didn’t really know the users and approached the job as a plus one responsibility.
We are excited to have inspired and led many of our clients through Agile transformations, but the work is far from over. The difference here, however, is now we have an opportunity to help clients that recognize the need to embrace something new, something unknown, and something that can significantly increase their chance for mission success.
We Found Agile BS, Now What?
The article talks to the various guides and guidelines provided by DoD to help identify Agile BS. In the guides, there are questions that speak to how software should be delivered to users at every iteration, how feedback loops should work on the team, and how that feedback should be incorporated into the project’s requirements. In the guide there are numerous questions for programming teams, program management offices, customers and users, and program leadership that should lead the interviewer to whether or not a program is actually using Agile.
The challenge with this overall premise is that the guide relies upon the person asking the questions actually understands Agile enough to effectively evaluate the answers. Some of the questions get sample answers that indicate Agile or BS, but this leaves the reader wondering where to begin when they want to remediate the non-Agile approach.
A New Command & Control System
Part of the article speaks to General Stanley McChrystal’s book, Team of Teams: New Rules of Engagement for a Complex World, and how his approach to leading the Joint Task Force in Iraqhad to change to meet the innovative nature of an adversary not willing to fight by the rules.Some of McChrystal’s discoveries through this experience related very closely to how Agile can be leveraged by large teams: bringing together teams into a common physical space, open communications amongst the teams for common situational awareness, and pushing down decisions to the lowest level rather than forcing a traditional command and control model where decisions are made (at some point in the future) by senior members of the team.
McChrystal’s observations from his experience in Iraq is a good example of how long-standingprocesses will not continue to be effective and reinforces the need for Agile processes throughout DoD.
Users at the Core
One of the most encouraging aspects of the article was the focus on communicating with users for continuous feedback and requirements gathering. The transformation from waterfall to Agile has a significant impact on the quality of the project being delivered, a significant increase in the transparency of the work being done, and precise predictability of when requirements can be met relative to the team performing the work.
The upside of this transformation is undeniable, but as with all disciplines there’s another level of Agile expertise that’s worth mentioning early on. Some of the questions in the article and DoD guides allude to the interaction with users. It is essential to place a primary importance onputting the users at the core of a project. Without this focus on the actual users, there is a tendency for appointed leaders, contracting officers, or at times even the contracted development team to infer what the requirements should be or how they should be interpreted, resulting in extreme disappointment or completely missed expectations.
We have witnessed this trend in even our most promising of clients that embrace Agile. The users these systems served get left out of the process, and ultimately, they are the ones that can make the biggest impact on the outcome of the effort. Due to this, Steampunk placesHuman-Centered-Design (HCD) firmly in the middle of our Agile and DevSecOps processes, ensuring the users’ needs are identified, their concerns are being addressed, and they are first-class citizens throughout the innovative solution development process our teams bring to our clients.
Summary
Steampunk is excited to see this kind of momentum for Agile in the government. Having seen the reluctant adoption of Agile over many years with our clients, the tools and techniques DoD are providing offer a great way for mission owners, program managers, contracts managers and government leaders to start to separate the good from the bad and fully utilize Agile processes to bring about more effectiveness to the government.
Over the years, our approach to Agile has helped our clients put their users and mission at the core, resulting in much stronger, more durable solutions. We have pointed out the pitfalls and traps, and helped countless clients realize the benefits that results from true Agile adoption.
I applaud the Department of Defense for leaning in on this topic and working hard to help their organizations to optimize their efforts to secure the nation and protect our warfighters. If the DoD, or any government organization for that matter starts asking the questions and hears answers that sound like Agile BS, we’re here to help.