Agile development has become such a holy grail in project management that some project teams have taken to waving the agile flag whether they’re true believers or not, throwing around talk of “sprints” and “scrums” without really meaning it. The Defense Innovation Board (DIB) is calling BS—literally. The DIB just issued a guide for the military titled “Detecting Agile BS” that aims to help Department of Defense officials separate the bona fide from the buzz.
The guide lays out signs that agile’s practices are being followed, as well as more significantly, the red flags that indicate when a project’s agile claims might not be as legit. If end users aren’t a regular part of the process, for instance, the project might not be agile. If you ask about recent sprint cycles and get a blank stare you probably want to look deeper into what’s going on. If meeting requirements seems like a bigger target than getting worthwhile software into the hands of users, you could be heading in the wrong direction.
Agile development carries risks of its own (such as less documentation, evolving requirements and an element of the unknown), but when it’s practices are being faked the risks can be amplified and a project can really go off the rails. DIB wants to help program executive officers and others see the signs before it’s too late. While its advice is aimed specifically at DOD, project and portfolio managers at all levels of government may want to take heed.
Agile on the Rise
By name, agile got started with the Agile Manifesto of 2001, which emphasized a faster, adaptive software development process that could keep pace with advancements in technology and business practices. The manifesto’s stated values favor individuals and interactions over processes and tools, working software over documentation, customer collaboration over contract negotiation, and responding to change over following a plan.
The idea was to get past the lumbering processes that were in place since the 1970s to get effective tools into the hands of users more quickly, with steady improvements built into the process. “Constant delivery” became a catchword of agile development, whose practitioners took to it with fervor. As the Agile Alliance points out, devoted followers adhere to the 12 Principles based on the manifesto. The alliance also has a Code of Conduct for anyone wishing to “apply Agile values, principles, and practices to make building software solutions more effective, humane, and sustainable.”
Agile has since become the dominant force in project and portfolio management. According to the Project Management Institute’s 2017 global survey, 71 percent of organizations say they use agile development either always, often or sometimes. In the federal government, the number of projects described as agile was 80 percent in 2017, according to a Deloitte analysis.
But as it grew in popularity, the term inevitably began to be used rather loosely, leading to it being tossed out as more of a sales pitch than a dedicated development methodology. In Gartner’s 2017 Hype Cycle for Project and Portfolio Management, Agile Project Management shows up among the terms that are “At the Peak” of the cycle.
Course Corrections
Agile isn’t the first—and won’t be the last—hot idea that has fallen into occasional misuse. Currently, artificial intelligence is so buzzy that some companies who don’t have the technology have taken to hiring humans to pretend to be AI bots. Before AI became the must-have attribute for anything involving software, every product had to be “smart.” Just to name two examples.
Hence the warnings from the DIB, an advisory board established in 2016 to help Pentagon brass bring the best innovation practices of the Silicon Valley to DOD. The 12-member board currently includes notable names such as Alphabet’s Eric Schmidt, astrophysicist and author Neil deGrasse Tyson, and Instagram COO Marne Levine, and focuses on three areas: people and culture, technology and capabilities, and practices and operations.
Among the guide’s red flags that the agile claim is not authentic is that users are kept out of the loop, DIB says. The software development team doesn’t spend time with actual users of the actual code (the program executive office or the commanding officer don’t count), nor are end users made a part of the development process; they should at least be part of release planning and user acceptance testing. Continuous feedback from users—as opposed to what can be gleaned from a quick meting at the beginning of the process—isn’t available.
Other signs of agile fakes: when meeting requirements take precedence over getting a usable product into the field as quickly as possible; and when the DevSecOps culture—which looks to bake-in security from the beginning—includes manual processes than can and should be automated.
The document also includes a fairly extensive list of questions to ask programming teams, along with examples of answers that should raise a flag. For example, if you ask how they test their code, you don’t want to hear that “OT&E is responsible for testing.” If you ask what they have learned in their past three sprint cycles and their answer is that they are waiting for management approval to begin, then they probably are not using agile. And if they don’t even know what a sprint cycle is, you have for sure called them out as agile fakers.
Knowing the signs of what isn’t agile can help agencies recognize what is. As well, the DIB includes a list of commonly used by teams that are used in agile development, such as the Git open-source standard, the BitBucket and GitHub repositories, and the Docker program that performs OS-level virtualization.
Agile development has had its detractors, along with its success stories. For the DIB, the problem isn’t with agile, it’s with those who say they’re using an agile approach in order to score points with the people holding the purse strings, but aren’t delivering the goods.
