Fake Agile is actually a real thing, and that comes from the US government. Granted, the US government may be one of the last places you’d look to determine if something were real or “fake”. Still, the real news of fake agile and a recently published report about how to spot agile bullshit really sparked my interest.
The DIB Report on Fake Agile
The particular report comes from an organization called the Defense Innovation Board. The article is straight up titled Detecting Agile BS. Which I have to say is both refreshing and ironic, coming from the US government.
In case you haven’t heard of the Defense Innovation Board, it is a group of technology thought leaders from the business world. This includes recognizable names like Eric Schmidt of Alphabet (Google), LinkedIn co-founder Reid Hoffman, and biographer Walter Isaacson. The purpose of the group is to “bring the technological innovation and best practice of Silicon Valley to the U.S. Military”.
Frankly I am not surprised that fake agile has become a real thing and a concern of the government. We have all seen fake or bullshit agile. I wrote about Agile in Name Only (A.I.N.O.) in my post about why people need to be trained in agile, and in this post about “agile” organizations that cling to the idea of the single throat to choke. I also wrote about the tendency for some people to equate agile and Scrum and see anything but Scrum as fake agile.
Tips To Help You Spot Fake Agile
The 5-page government publication provides some background on agile principles and values, a list of common agile development tools and a few lists of questions to ask developers, program managers, customers and leaders to determine whether they are using fake agile. The DIB publication also includes a list of flags or tells to help you spot fake agile:
- Ignoring users – Developers are not talking with or seeing users of the application; lack of continuous feedback from users to the dev team; end users are MIA, particularly in user testing and release planning
- Attention to requirements over quickly deploying something useful
- Participants act like ‘it’s not my job’
- Reliance on manual processes rather than automation / DevOps
This was one of the more interesting things I’ve read that the government has published. Another that I liked was the Simple Field Sabotage Manual.