Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

media.defense.gov

Post reply on HN
Print view View original

31–40 of 58 posts

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

#31

Post by ngngngng »

Interesting that all these issues are completely different from my own experiences with Agile BS. We would have 10 hours of exhausting meetings every 2 weeks in order to plan our sprints. Unconsciously, we just ended up hyper inflating estimates so our team would joke about how the only thing we did each sprint was "slap a box on it" (in CSS, or some similarly simple task).

I left that job when all the developers completed their tasks a few hours before the end of the sprint, giving me (QA) just a few hours to test, merge, and deploy their code, which because of our terribly clunky and manual deploy system, just wasn't possible. I was placed under an internal investigation for not being productive because I held up the sprint of the "most productive team in the company" and made us look bad to out of state executives.

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

#32

Post by Jtsummers »

qznc wrote: post #14
jrumbut wrote: post #8

Earlier quoted context omitted.

I think the parent post has, but for the reader who is a software engineer take 15 minutes out of your life to read WW Royce's "Managing the Development of Large Software Systems." In this brief and engaging paper you will find the diagram used by many agile enthusiasts to describe the "waterfall method" and will be shocked to discover that it is held up as an example of a process that never actually works in reality…

http://beza1e1.tuxen.de/waterfall.html Incremental and iterative development is not an invention of Agile either. It was used before "Waterfall" existed.

It's important to realize that Agile didn't invent anything. Agile was coined after years of work by numerous people to develop (or incorporate) different ideas into their methods. That is, as far as incremental & iterative development is concerned, history literate Agilers wouldn't claim to have invented it, but perhaps to have placed greater emphasis on it.

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

#33

Post by bitwize »

vbtemp wrote: post #21

I love the document and will distribute to my co-workers. The short story, however, is not really that there's a checklist to determine BS Agile, but rather that all/most Agile is BS. In my career I've seen "Agile" throw a wrench in the works for so many projects. Embedded systems; data center distributed systems that are air-gapped; aerospace safety systems; R&D work. Agile in these cases just isn't the thing to do,…

The advantage that Agile brings to the table is that it enables more tracking and measurement at finer-grained time intervals than other approaches. Tracking and measurement is the key feature of Agile or any other software development methodology. It enables the business to determine what needs to get done, if it's on track to completion, and if not, what the pain points are. Having a short OODA loop for these three points is paramount to the business's success and in order to do that you need to track and measure. You can't manage what you can't measure, and Agile processes give the business data and analytics about how their development efforts are going at least at a sprint level of granularity; depending on local practices it could be as fine as one day. That's huge. It could potentially add visibility to all aspects of the business -- so get ready to see Agile everywhere.

TL;DR, if you believe Agile was created to help you do your job better, you might also believe that open-plan offices were really adopted to "foster collaboration" and not make you easier to spy on at work.

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

#34

Post by commandlinefan »

eru wrote: post #2

Great document overall! > The purpose of this document is to provide guidance to DoD program executives and acquisition professionals on how to detect software projects that are really using agile development versus those that are simply waterfall or spiral development in agile clothing (“agile-scrum-fall”). Actually doing 'waterfall' properly would probably be fine? Or at least not the bogeyman it's made out to be.…

> Or at least not the bogeyman it's made out to be

Well... why do you think it's made out to be the "bogeyman"? The reality is that people tried (and continued to try) to run software projects that way: state up-front everything you're going to do, and then do it! What could be simpler?

Anybody who's ever tried to do that has run headlong into the reality that: they didn't know up-front all the things they were going to need to do. For a long time, people believed that this was just a matter of experience and perspective and, after a reasonable amount of practice, software developers would be able to not only recite each task ahead of time, not only predict how long each was going to take, but would be able to do so in orders of magnitude less time than the actual task would take.

This view of software development imagines programming as mostly just typing without much more thought involved than, say, laying bricks. That this model, if accurate, could be automated away seems to escape the attention of the project managers who insist on managing software projects this way. If it were possible to specify software in such a way that it could be predicted and planned out the way "waterfall" demands, it could be automated to take humans out of the equation completely. (And the project managers themselves could be replaced with a spreadsheet).

If you go back and read the original Agile manifesto, it was written by people who were trying to explain that software is inherently unpredictable or - more to the point - that the parts of software that you need humans to perform are the unpredictable parts. There's an old saying, though, that nobody ever went broke telling people what they wanted to hear, so a cottage industry of agile "consultants" who'd never tried to develop software themselves made fortunes telling upper management that software is, as they wished, completely predictable, and the only reason schedules slip is because they're not mistreating their programmers harshly enough.

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

#35

Post by dionian »

ngngngng wrote: post #31

Interesting that all these issues are completely different from my own experiences with Agile BS. We would have 10 hours of exhausting meetings every 2 weeks in order to plan our sprints. Unconsciously, we just ended up hyper inflating estimates so our team would joke about how the only thing we did each sprint was "slap a box on it" (in CSS, or some similarly simple task). I left that job when all the developers com…

testing should have been part of the estimates and you should have thrown that right back at the rest of the team during retro

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

#36

Post by vbtemp »

eru wrote: post #2

Great document overall! > The purpose of this document is to provide guidance to DoD program executives and acquisition professionals on how to detect software projects that are really using agile development versus those that are simply waterfall or spiral development in agile clothing (“agile-scrum-fall”). Actually doing 'waterfall' properly would probably be fine? Or at least not the bogeyman it's made out to be.…

Approximately 13 years in the field. At least four to five different organizations. Worked on everything from embedded aerospace systems to web apps and everything in between. Start-ups, mega-government labs, and again everything in between.

I've never seen a project use "Waterfall". It's just not a thing. People use it as a hypothetical boogeyman to "Agile".

As with everything "Agile", all words lose meaning.

Edit: There DOES exist the CMMI Systems Engineering processes, that generally involve various design reviews (PDR, CDR), IOCs, FOCs. These are essential for large-scale procurement that perform mission-critical functions. Superficially similar to "Waterfall", it still isn't. For example, you don't want to be on an aircraft or spacecraft that was "Agile"-ed to completion.

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

#37

Post by vbtemp »

ngngngng wrote: post #31

Interesting that all these issues are completely different from my own experiences with Agile BS. We would have 10 hours of exhausting meetings every 2 weeks in order to plan our sprints. Unconsciously, we just ended up hyper inflating estimates so our team would joke about how the only thing we did each sprint was "slap a box on it" (in CSS, or some similarly simple task). I left that job when all the developers com…

This is because words lose all meaning with "Agile".

Functional teams and companies will make good products and set up their staff for success, with or without agile.

Dysfunctional teams will have all sorts of perverse incentives and set each other up for failure, with or without agile.

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

#38

Post by ngngngng »

dionian wrote: post #35
ngngngng wrote: post #31

Interesting that all these issues are completely different from my own experiences with Agile BS. We would have 10 hours of exhausting meetings every 2 weeks in order to plan our sprints. Unconsciously, we just ended up hyper inflating estimates so our team would joke about how the only thing we did each sprint was "slap a box on it" (in CSS, or some similarly simple task). I left that job when all the developers com…

testing should have been part of the estimates and you should have thrown that right back at the rest of the team during retro

Exactly. But my team didn't think it was a problem, we just forgave ourselves and moved on and I finished testing and deploying early in the next sprint. The problem came when external executives noticed how little we completed compared to our usual throughput and insisted that I be punished for it since I was the bottleneck. My team was just as confused as I was, but I had been meaning to move from QA/Test automation to being a developer for some time, so that just hurried me along and I left within a couple weeks.

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

#39

Post by zoomablemind »

What's DIB? Just trying to understand who is the target audience of this guide.

It's a practical set of traits to spot. But inevitably a question comes up "what to do next?" Re-educate, enforce, hire/fire, disband?

One needs to remember how the Agile processes were being "installed" back in the day in organisations/teams of various degree of dysfunction. Lots of those teams went through trials of "templates", including waterfall, just with the same outcomes.

Too often, the failure is not at the team but on org-level. The base tenet of Agile success is buy-in on all levels. Yet it's easier for the management to "buy-into" a structure and attributes, not into actually empowering and trusting the teams.

So, this detection approach may find all right attributes, tools, lingo, roles... but not the actual practices. A beaten down example is a morning stand-up, which disguises the dreaded subordinate reports - best indicator of such theater is a presence of a "clip-board" or note-taker person.

I'd think for such guide to be of better practical value, there should be a section which would outline ways to detect the constraints and obstacles for adoption of a proccess which would be effective in a given team's case. It does not have to be Agile-or-wrong.

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

#40

Post by Jtsummers »

zoomablemind wrote: post #39

What's DIB? Just trying to understand who is the target audience of this guide. It's a practical set of traits to spot. But inevitably a question comes up "what to do next?" Re-educate, enforce, hire/fire, disband? One needs to remember how the Agile processes were being "installed" back in the day in organisations/teams of various degree of dysfunction. Lots of those teams went through trials of "templates", includi…

DIB = Defense Innovation Board, https://innovation.defense.gov

Made up of various tech industry leaders (mainly CEOs, it seems). The purpose was to try and modernize the way, or present a path to modernization, defense software systems are developed and maintained. Because it's presently a cluster fuck.

Post reply on HN