
DIB Guide: Detecting Agile BS (2018) [pdf] - nfrankel
https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB_DETECTING_AGILE_BS_2018.10.05.PDF
======
commandlinefan
What makes the state of “agile” processes in modern software development so
depressing is that actual agility is worthwhile and – if anybody were actually
to adhere to actual agile project management principles – achievable. However,
I’ve been through at least a dozen agile “transformations” over the past 20
years or so since XP kicked off this whole trend and they all end up going
like this: management hires some “agile consultants” who don’t have much (or
sometimes any) actual software development experience, so they see software
development as sort of an assembly line process to optimize, Taylor style.
Under that model, software developers are skilled (or semi-skilled) widget
assemblers, and management creates tickets for the software developers to
“assemble”. The agile consultant’s role, then, is to make that happen as fast
as possible. Since it’s just a matter of assembling some “computer stuff”,
every task is predictable: an experienced assembly line worker with one or two
years of experience ought to be able to look at a widget/ticket and estimate
+/\- 5% exactly how many hours it should take to complete. Any widget/ticket
that’s estimated > 1 day can be broken into multiple smaller tickets of < 1
day each. If this isn’t the case for any of the tickets, the whole model
breaks down and, since we don’t want the model to break down, this must a
priori be true: if one of the assembly line workers takes too long on a task,
the fault must lie with the assembly line worker, because, the assumptions
have already been established to be accurate.

~~~
devonkim
Your reasons for why “Agile” isn’t working is the same for why “devops” isn’t
working - the enterprise refuses to let go of fundamental practices and
assumptions of Taylor work models where planning is centralized by a manager
caste and concerns for individual contributors are mostly cast aside (Deming’s
approach is the opposite and is what the Japanese auto makers used to improve
quality and dominate the US auto market in a matter of a decade). Furthermore,
a great deal of the places in a crisis (seriously, why go through an expensive
transformation if you’re fine?) have lost most of their software craft and are
culturally bankrupt to do much more than manage things and watch them fail.
Execution on anything besides sales is missing completely while an offshore
team or a bunch of engineers too tired / hungry / captive to protest their
conditions are dragged through it all.

Most of the Agile coaches I think know this and just want their cash before
these places sink (takes maybe 15 years, enough time for a decently long
career), and if maybe one of these places is saved they can feel good. But
really, I think the situation isn’t too different from what Mitt Romney’s
private equity firm was accused of doing for decades (and anyone else in PE
for that matter).

~~~
outworlder
> Your reasons for why “Agile” isn’t working is the same for why “devops”
> isn’t working

Thank you. This brightens my day.

Far too many companies want to appear "up-to-date" with the "industry
standard", so they rename their ops team as devops and call it a day. Maybe
add some automation-focused reqs to justify the change. Ops with some ansible
and terraform sprinkled on top are still ops. Just call it ops.

~~~
devonkim
Having tried to hire for a team that is focused on operations there’s a huge
world out there full of engineers that have hid their head in the sand about
configuration management, infrastructure as code, etc. They may have managed a
lot of network devices, SANs, AD and Exchange clusters, etc. But devops really
started within the software community fundamentally rather than the modern
sysadmin one and there’s a lot of distinct differences in mentality that
shows. This doesn’t mean one is better than another but if tou’re in the
technology field it is imperative that you stay up to date on what’s going on
even slightly adjacent to our respective fields. This has been lost on a lot
of otherwise excellent sysadmins though, and for that reason alone I have to
decline good engineers - attitude and perspective over a long career being
unsuitable for the company I’m hiring for.

~~~
outworlder
> But devops really started within the software community fundamentally rather
> than the modern sysadmin one and there’s a lot of distinct differences in
> mentality that shows.

That is true.

> and for that reason alone I have to decline good engineers

Ultimately, that's the right call. Once certain a way of thinking solidifies,
it is very hard to change.

------
harryf
This is a great document, especially with the DoD name on it to give it
weight.

> Key flags that a project is not really agile: Nobody on the software
> development team is talking with and observing the users of the software in
> action; we mean the actual users of the actual code.

This one is a largely a "comfort zone" problem IMO;

\- Recruiting users, especially for B2C products is tricky

\- Management get nervous about "unwashed developers" talking to customers

\- Developers have to leave cosy offices

\- In remote teams it's even harder

\- It's tricky to schedule without disrupting normal work

\- Imagining the world and designing features for it in a cosy office is a
great ego trip

\- Nobody really knows how best to interact with users

\- Business people get nervous about developers having opinions

... etc.

Many places I've seen even Product "Owners" never talking to users and
basically spending all time managing the backlog.

All very comfy and getting out of that comfort zone takes significant effort.

I once gave a talk about the fundamental flaw of much mobile app development
which is summarized in this slide -
[https://i.imgur.com/v1qmR8m.jpg](https://i.imgur.com/v1qmR8m.jpg) ... the
"older generation" making apps on big screens, fast networks while sat a desk
for a younger generation on the move, that barely knows what a mouse is.

~~~
perfunctory
> Nobody on the software development team is talking with and observing the
> users of the software in action

On every new project (usually internal enterprise software) I plead to let me
talk to the users. Every time in vain.

~~~
clairity
as fouc noted in a sibling comment, you shouldn't need to ask for permission
to talk to customers if the organization is truly agile. however, the product
owner (which i've been in various capacities) should bring a lot of customer
information to the table so you can focus most of your time on development.

it's unfortunate that your organizational structure prevents you from doing
so.

~~~
kashyapc
Even if a "Product Owner" brings a lot of customer information, it is still
damn important for those developers who are genuinely _willing_ (and able), to
interact with customers— _even if_ it is only via medium-bandwidth tools like
video calls. Developers should not worry about spending some time talking to
users.

~~~
clairity
we are not "disagreeing" that develoeprs have freedom to talk to customers.
but if a developer spends most of their time doing something other than
development, there are other inefficiencies going on.

~~~
kashyapc
I know we agree on some level. Still, I can't help but feel like you have a
somewhat narrow definition of "developer". A thoughtful senior developer who
is in it for the long-run (read 15–30 years), and thinks in terms of "building
a craft" will (and must) aim for a more well-rounded set of skills (that does
not involve "development" in the narrow sense of hurling code)—e.g. giving
high-quality technical talks that provide _durable_ value, high-bandwidth
interactions with customers and users, writing specifications, bringing
multiple technical teams together to architect features and solutions (which
requires careful and _effective_ communication), and so forth.

Related: You might've already come across it, if not, I suggest reading this
paper (it's not about any specific technical topic, but more about the thought
processes) from Peter Naur, titled: _Programming as Theory Building_.

[1]
[http://pages.cs.wisc.edu/~remzi/Naur.pdf](http://pages.cs.wisc.edu/~remzi/Naur.pdf)

------
shubb
Do we have any evidence that Agile actually helps, and for what kind of
projects / companies it helps?

It's just I note this is a DOD document, and I don't think we should be
desiging jet fighters in 2 week sprints. Airframes probably can't be modified
like that. So it follows that, within a waterfall project, the flight software
shouldn't be developed agile either.

Beyond that, I don't think safety critical systems should be produced code
first. We should probably be doing modelling and formal verification and stuff
like that.

I think agile is a great way of making e commerce websites.

Sure, XP came out of NASA, but XP is a specific thing. Not working overtime is
important in XP.

'Modern Agile' on the other hand cares about things like producing an MVP and
iterating, which originated in and are appropriate in a web startup context.
I'm not sure they should be forced in an engineering context.

~~~
starpilot
I felt like Agile was like rewarding people for rats tails, so people start
breeding rats. There was too much focus on clearing out stories, even if it
meant a ton of bugs, but the bugs were good because those led to more stories
and the PM could take credit for "getting so much done." This was at a certain
dysfunctional, highly political networking hardware company.

~~~
aaaaaaaaaab
So that’s why all network gear needs to be power-cycled at least weekly to
function correctly!

~~~
outworlder
No, although that could be part of it.

You are probably talking about consumer gear. Consumers usually have two
requirements: a) FEATURES FEATURES FEATURES. All of them. 200 beamforming
antennas. Interplanetary internet. b) Price. All of the above for the lowest
price possible. FTL communication? Cool. It better be under $50 or I'll buy
the competitor.

So this is what the companies optimize for. Who cares if DHCP is broken if it
works most of the time. Memory leak? Just have it reboot. IPV6 broken? Most
customers won't even know or care.

You'll find that 'enterprise' hardware performs way better. At a price
premium.

------
aristophenes
There are so many spot-on things in this document that I cannot share it with
the appropriate people in my organization as it will be seen as an attack and
offensive insult. Not sure how I could be gentle about it, it's quite damning.

~~~
harryf
You could anonymously print it and stick it on the wall next to the coffee
machine

~~~
aristophenes
Unfortunately I work remotely. I think my wife would suspect it was me ;)

------
montenegrohugo
Surprisingly reasonable & well written.

I wonder who wrote this, sounds like a person with extensive experience with
contractors that sell themselves as 'agile' but really have no idea what the
term even means.

EDIT: These actually seem like great questions to ask at an interview to a
potential employer

~~~
ddebernardy
I wish it was only contractors. I've seen my fair share of startups over the
years that were nothing but. And heck, I'm no agile specialist by any stretch,
and I'm often first to point out how god awful it's being implemented in
practice. But the one thing I grokked about it is that if you're not talking
to end-users each sprint you're not agile plain and simple.

(And agreed these are good questions for would-be employers. But if you do ask
them and refuse to work in a non-agile shop, you'll find precious little
outfits to work for.)

------
YeGoblynQueenne
Funny story. I once worked in a mainframe team at a large financial org that,
since the company was going through a period of "digital transformation" (or
some such weird corporate jargon that I have suppressed) declared itself agile
and had scrums, a kanban board, a scrum master etc agile trappings.

... and ten-page long Word forms with 15-item drop-down lists that had to be
filled in before a single line of JCL could be changed (we did not touch the
COBOL. Nobody touched the COBOL).

------
nwhatt
I love this and thanks for sharing.

I'm glad that we're starting to develop a backlash to "Agile Industrial
Complex" and "Dark Scrum". At the end of the day, it may be hopeless though.
Being able to read and internalize the Agile manifesto is hard. Just like
design thinking is way harder than process thinking. Successful companies will
empower developers, middling to failing companies will continue to view them
through Taylorism.

~~~
commandlinefan
> it may be hopeless though

I fear it is hopeless. After all, XP - which morphed into the umbrella term
"agile" \- was a direct response to the failings of the software project
management fads of the time... which are exactly what has been warmed over and
served up as "agile" now, 20 years later.

------
FavouriteColour
Six months ago I joined an "agile" team. The team is completely disconnected
from any reasonable interpretation of agile.

No sprints.

No stand-ups.

No prioritized backlog.

No sprint planning.

No sprint reviews.

There is a product owner, who is a BA, but I never speak to her. She's on a
different floor.

If I want to work on something, I literally have to ask the other developers
if anyone has anything they need done.

When I joined the team, we had a project manager who would create tasks in
jira and assign them to individuals. When the task was finished, we assigned
them back to the PM so he could assign them to a tester. The tasks were
already broken down from user stories so I would often get "implement REST
service for X" and someone else would get "implement web page for X".

We have a new project manager who doesn't like agile. He is currently
"resetting" the project by forcing the business to write a complete set of
detailed requirements. They have until June 30 to finish that. In the
meantime, the team will continue in a kind of limbo of "agile" but the PM has
already committed the team to completing the project by Dec 31st even though
the requirements won't be finished until Jun 30th. The budget is also fixed.

I've asked the team why we don't do any of the agile things. Normally you'd at
least get cargo cult stand-ups. They said they don't see the value in it.
They've all been working on the project for 2+ years so they know what needs
to be done. I pointed out that it makes it impossible for me to participate in
the project in any meaningful way since I'm reduced to begging for work. They
don't see a problem with that. "Just ask".

Because it's "agile" there is no up-to-date technical documentation. So to get
anything done (once I have work to do) involves finding out who in the team
knows what I need to know and interrupting them. The guy who knows the most is
a terrible communicator. "Just ask".

I have an interview at another place on Friday. I think people will be
genuinely surprised when I tell them I'm leaving.

------
AnimalMuppet
FTA: A question for management: "What have you learned in your past three
sprint cycles and what did you do about it?"

That's a _great_ question for detecting "fake agile". In real agile, your
process is something that you tweak and optimize as you learn things.

------
kradroy
I'm a manager who recently transitioned my team to Scrum. I see many parallels
from the doc to my team vis-a-vis the Scrum process as implemented by our
scrum master. I think it's an awful process and I'm questioning whether it was
the right move. I don't really see any improvements despite my engineers'
desire to adopt it.

It seems to help junior engineers by making them comfortable tackling
unfamiliar systems and code. However, it's completely slowed down my senior
engineers. I feel Parkinson's Law (work expands to fill the time allotted for
it) creeping in. The scrum master encourages the engineers to be conservative
in their sprint workload.

I suspect if my engineers were more enthusiastic and proactive, it might have
paid off. However, I think enthusiastic, organized and proactive engineers
don't need any process to be productive.

~~~
commandlinefan
> completely slowed down my senior engineers > if my engineers were more
> enthusiastic and proactive

You should definitely get rid of all of them. They're holding you back. Free
them to pursue other opportunities, because it's obvious that you would be
taking over the world if you weren't hamstrung by lazy, coddled, overpriced,
whiny complainers. After all, even if you don't have the budget to offer what
the absolute best and brightest might command somewhere else, I'm sure that
the most talented engineers would jump at the opportunity to work for and with
a true visionary like yourself.

~~~
kradroy
You're a true leader with your inspiring, insightful comments.

I've worked with these engineers for the past 5 years as a technical lead and
as their manager. I'm thoroughly qualified to pass critical judgment on them.
I instituted Scrum because _they_ asked for it thinking it would be helpful.
It hasn't had that effect. My point was that process means little if your
people aren't engaged.

------
obelos
Given the budgetary/bidding process that funds and contracts government and
especially DoD projects, how is an iterative approach even possible? How would
the CO know and be comfortable signing off on saying yes, the terms of this
contract are being fulfilled?

------
TheSoftwareGuy
I work for a defense company and this pretty much describes our development
flow.

Who thinks I should show this to my manager?

~~~
okl
Constant dripping wears the stone is my advice. You have to phrase/wrap your
critique in positive words or your opinion will be met with disdain.

------
Yoms
This seems to be a root document with more links:

[https://media.defense.gov/2019/Jan/14/2002079285/-1/-1/0/TL;...](https://media.defense.gov/2019/Jan/14/2002079285/-1/-1/0/TL;DR_TOC_DIB_SWAP_V1.5_2019.01.11.PDF)

After having worked on government contracts for many, many years - this is an
amazing leap forward - I had to do some googling. DIB is the Defense
Innovation Board
([https://innovation.defense.gov/](https://innovation.defense.gov/)) which
consists of some big names (Neil Degrasse Tyson, Eric Schmidt, Reid Hoffman,
Marne Levine, among others).

------
sailfast
Some more detail / statements from the Board from October RE the document and
efforts to combat this (imho rampant) problem:

[https://www.fedscoop.com/defense-innovation-board-wants-
help...](https://www.fedscoop.com/defense-innovation-board-wants-help-
military-recognize-agile-bs/)

This was fun to read. I think the charge will be led by a few areas within DoD
that have been newly stood up but it doesn't take long for something that
works and is shiny to become a best practice especially if it brings money in
the budget along.

------
okl
I expected to find more negative examples based on the title. With that
document alone (esp. last page) it's difficult to spot BS unless you get a
binary yes/no answer.

------
whieee
Surprisingly clear document, completely free of BS itself.

~~~
okl
Except for the title.

~~~
Quarrelsome
you wanna do it in less words while retaining the precision?

~~~
okl
The title literally contains BS. So… Whoosh!

~~~
Quarrelsome
oh I getcha, my bad :D

------
tensor
Unsurprisingly, there is no notion of UX/UI design or user research or
usability testing in this process at all. It makes the assumption that
developers are good at everything, including all non-programming tasks.

This is all too common in software development, and decidedly old-fashioned
thinking in the modern world of design driven development.

~~~
williamdclt
I wouldn't say that assuming that "developers are good at everything,
including all non-programming tasks" is old-fashioned. At the contrary I would
call "old-fashioned" the idea of the caveman dev who only talk to their
computer.

That being said, I agree that it's assuming a lot from developers, but that's
a working recipe for a successful project. If you have another way, please do
share it :)

~~~
tensor
This is not a working recipe for a successful project if you count good UX as
part of the requirements. The modern way is full stack cross functional teams.
You need UX designers working with developers, not to mention other domain
experts depending on what you are developing.

I never said anything about "caveman dev." Software development is a
challenging area, but being good at creating software does not make you good
at other things. Some industries, like game development, have long had cross-
functional teams where developers, designers, artists, writers, all work
together.

In my opinion, any agile process that doesn't address UX design is outdated.

------
kvhdude
I work in networking infrastructure products in embedded systems. I never
understood the appeal of agile/devops style development for anything whose
failure has immediate and widesperead consequence. For e.g would you add
features to a deployed compiler in an agile manner? (throw it out there to see
what sticks?)

------
bsder
> Customer collaboration over contract negotiation

Uh, yeah. NOT!

This is the government. If you don't have a contract, you are not getting
paid. Period.

Agile is great when both parties are working in good faith. Government
procurement, by both law and definition, does not work that way.

~~~
scur7
An important part of the agile manifesto that is sometimes missed is that it
is not saying there is no value in the items on the right (i.e. that you
should not have contracts). An agile way of handling contracts is to negotiate
smaller contracts (for example a contract to build the first vertical slice of
a system rather than one contract for the entire system) to allow either party
to easily move on (fail fast) if things don't work out.

------
m0zg
I thought the DoD caught on to the fact that "agile" is, in fact, BS.
Apparently not. It'll take them another decade of "sprinting" to nowhere to
figure this out.

------
winrid
I actually had management tell me it's a problem that my team is agile but not
Agile. Sigh...

------
winslow
I was really hoping DIB stood for Department In Bullshit.

------
mshockwave
Just feel amusing this was written by DoD

------
icedchai
Interesting, since "agile" itself is actually built upon bullshit.

