How to spot fake agile software

The rampant misuse of software buzzwords has become a national security concern. This according to the Defense Innovation Board, which not long ago issued a guide to help the Defense department detect agile BS. The report is not only a blunt admonishment to contractors, but also a tool to help the department cast out fake agile, projects described as “simply waterfall or spiral development in agile clothing.” It articulates what's become a common frustration for government procurement officials, that “all DoD software development projects are, almost by default, now declared to be agile.” It might seem like mere semantics, but terms like agile and DevOps carry specific meanings and, when abused, create widespread confusion or worse. Some argue fake agile gone unchecked significantly damages the department's cyber warfare operations. Who’s really agile, and who’s only faking? To learn more, we welcome Brett Parker, a senior software engineer at Leidos, who helps oversee the company’s agile software factory initiative.

Q: What’s fake agile, and why is it so damaging?

Brett: “Fake agile” is agile software development that’s agile in name only. People say they’re agile all the time, but a lot of times they’re still following a waterfall practice, or they’re just doing two week sprints and calling themselves agile. This creates a really bad atmosphere for our customers. When you tell them you’re agile, they might think it’s terrible based on their experience. But it’s not that agile is terrible, it’s just that they’ve worked with a poor practitioner of it. Fake agile presents a national security risk because our customers constantly need new software-based tools to carry out their missions. True agile software development gives them the ability to adapt very quickly.
 

Q: How widespread has fake agile become?

Brett: We’re seeing it everywhere. Some companies are even putting out marketing papers claiming they’ve “arrived” with an agile practice, implying that agility is a destination. This is actually proof they’re not paying attention, because to be truly agile requires constant improvement. If you’re not always improving, you’re going to be stale and stagnant almost instantly. I’ve been in meetings where high-ranking decision makers say something like, “Oh, I don’t like that agile stuff. I’ve heard really bad things.” But after a 30-minute discussion, we can change their minds. It turns out they’re not against agile. They’re against bad agile and fake agile. And those are important things to be against. As people continue to sell agile because it’s the latest buzzword, companies who are really practicing agile will have to fight that uphill battle.

Q: What practical advice do you have for weeding out fake agile?

Brett: We encourage our customers to ask their contractors whether or not they’re able to deploy mission-ready software to the end user every two weeks. If the answer is no, they aren’t really agile. Second, we advise our customers to detect fake agile during the procurement process by moving from traditional paper-based proposals to coding challenges. Contractors should be required to prove they can write software with speed, quality, and security by delivering a piece of software during the proposal period itself. We’re starting to see this more and more, especially in our civil business. It’s a great litmus test, and it’s starting to gain momentum here and there.

Q: What’s the best program you’ve seen that demonstrates the value of true agile?

Brett: Our C2IMERA (pronounced chimera) program is the first externally developed program to run on the U.S. Air Force’s Kessel Run environment and tools. Starting in 2014, we took over an incumbent's program that was operating with 25-month code deployment cycles. Since then, Leidos has modernized the architecture and increased deployment speeds; we now deliver new releases to the field every two weeks. One of the reasons end users love the program is they're able to see their inputs and requests realized in rapid, subsequent releases. That's how Leidos does agile.

Q: Why is this focus on the end user so important?

Brett: The best software is driven by its users. It satisfies their needs. We call this user-driven design or user-centered design. All software should start with the user. There’s been research that shows a large number of software features go unused. That means end-users are getting features they don’t need or want while potentially sacrificing features they do. By including end users in the development process, we’re able to develop the right features that provide real value.