DIB Guide: Detecting Agile BS (2018) [pdf] | Hacker News Reader

DIB Guide: Detecting Agile BS (2018) [pdf]

media.defense.gov

67 pointsPoignardAzur16 comments

Agile Value: Individuals and interactions over processes and tools

DIB Mapping: “Competence trumps process”

This makes sense to me, that said: how do you commodify competence? I'm thinking about the teams I've worked with that do agile but wind up writing an objectively difficult-to-maintain codebase because they lack competency in anything that resembles best practices. I will commend the teams for shipping large products and doing agile though.

The question you ask is basically "how to get good at developing software?"

The key components are (a) exposure to a wide variety of circumstances that require new skills, and (b) appropriate feedback on performance.

Some practical ways to achieve this:

- Allow people to make mistakes and fail in a safe social environment. Even if you watch the intern as they are about to reboot the prod database, see what happens. I bet you they will learn something -- and so will you!

- Staff teams with a majority of experienced developers (at the very least 5 years, ideally 10 or 15).

- Have developers operate the software in production.

- Encourage a high bar in code review.

- Involve the same developers from start to finish (initial prototype, first production version, maintenance period, sunsetting) of a product.

- Embed useful metrics for availability, performance, resource usage, etc.

This document, I think, cuts right to the heart of it: if you're not talking to the actual users -- the ones with the pain point you're ostensibly solving with your software -- you're probably not agile because the feedback loop is too long. And because the feedback loop is too long, it becomes costly to make changes (because time is cost) so you end up back at waterfall to mitigate those costs and risks.

My conclusion: it's probably impossible for any sufficiently large organization to truly be agile.

There are too many fiefdoms obfuscating the product team from the users.

Back when we weren't doing Agile, I was talking to my users.

I did watch their patterns and habits via the logs, especially when switching systems, because the question "How was this system actually used?" is dreadfully important. But sometimes I would see a student using something I had made and would point blank ask them about their experience. Is this reliable? Is this okay? Any problems?

And, you know, there are times when saying "I wrote this, I will come to your office and see what is going on" is very valuable when surveys aren't. "They" tried to stop me but I ignored them, because playing a game of telephone with errors is complete trash.

I don't think it's the organization size at fault, I think it's a culture of controlling information. In defense contexts, the "customer" puts out a list of requirements they want satisfied and expect the bidders to stick their head in the sand and not ask further questions. How could you possibly be agile in that environment?

> How could you possibly be agile in that environment?

You couldn't. There are a lot of real-world scenarios where you can't be agile. For one, it suggests that it won't work if you don't have motivated individuals. There aren't enough motivated individual developers to go around, so someone is going to get stuck with unmotivated individuals and won't be able to be agile.

Such is life. It is not some kind of commandment. It's okay to not be agile.

> This document, I think, cuts right to the heart of it

I think that's the big strength of this document: it identifies the top priorities for the project, and hard-and-fast rules to judge whether those priorities are met.

A lot of presentations about agile are vague and open-ended. I like a document that says "if you're not doing X, you're doing it wrong", I wish that writing style was more common.

I think a large organisation absolutely can be agile... but you will have to rethink what organisations are and how they work, dispense with things like orgcharts, and the way that power works and think about the underspecified parts of agile - i.e. strategy, team coordination and so on. The book Team Topologies outlines something that looks very much like it tbf...

As someone who programs in the military, this paper rings true in an absurd number of ways. A lot of these problems are unavoidable - you have to have some requirements when it comes to very dangerous systems, for example - but there's a lot of people who pretend what we do is Agile even if it clearly is not.

And I think that at some point, doing some agile is still better than doing nothing. We code to requirements, but still have sprints/sprint plannings, stand up meetings, point system with tickets, etc because it gets things done faster. But that still must be done even though we can't directly interact with the users. It's not agile, but it at least makes an attempt to get work done.

In some ways I think the name "Agile" is a misnomer. The fact is most projects are as you described. Agile provides a way to reliably manage a project, identify blockers and break the project down in to manageable chunks aiding in gauging whether progress is being made.

The problem for me with almost all managements methods is they become metrics for management to improve productivity. They start doing things like wanting to increase velocity to increase productivity. Or comparing 2 groups by comparing their velocity. Or not having long term goals because they think everything you do has to fit into a 2 week sprint. The list goes on.....

I think a large part of the problem across industry, and I say this having worked from startups to software companies to DoD, is that "agile" has co-opted the definition of the word "agile", at least in-part with Google's help turning everyday words into weaponized cliches which is too long a subject for this writing.

Thus, "define: agile" gives:

Characterized by quickness, lightness, and ease of movement; nimble. Mentally quick or alert.

My personal definition stems from reading a combination of Alistair Cockburn laced with Alan Holub. Combining:

Teams that are alert, light, nimble, and quick.

My experience has been that there were two teams I've been part of that had those qualities:

1) Pre-Y2K teams that arrived at the agile manifesto having no jargon, only action and insight. 2) Teams that had the luxury of agility because they were size-constrained by finance.

I'd emphasize that you don't do agile. Doing agile is part of the problem of cliched cargo cults.

Rather, you either are or not agile as evidenced by your results or outcomes repeated on a regular cycle followed by the gold standard of sensemaking: retrospective.

The problem is not scaling technology. The problem is scaling agile humans since communication does not scale linearly when it leaves a single skull. What we are missing is an order of approximation (Big-O) for teams. The closest I've seen is maybe this:

https://getsturdy.com/blog/2021-11-29-scaling-teams

I find little evidence that there is emergent research around this.

The common theme seems to be a tight feedback loop between developers and customers. Stakeholders acting autonomously is a big flag they called out, too. I would be interested in reading an updated version of this draft if anyone knows of one.

Here's the list of publications from the DIB:

https://innovation.defense.gov/Recommendations/

And here's the final version:

https://media.defense.gov/2019/May/02/2002127286/-1/-1/0/DIB...

It's a good check against your own organization. Back in the old days there was the so called "Joel test" to measure if your organization practices modern development standards. Agile is a good successor to this test. You'd be surprised how many aren't doing agile yet still call it because everyone does or actually have their understanding of agile derived from every imaginable anti-pattern. I know that many here don't like certifications but they show me at least that the person has been engaged with the material.

Is it normal for a government paper to be written in such a "casual" manner? This feels like it was written by someone young, or in a chat.

Bit of a stretch on mapping "Customer collaboration over contract negotiation" to "Adopt a DevSecOps culture for software systems."

DevSecOps itself should be in the page 5 grey pool.

Reply on news.ycombinator.com