DIB Guide: Detecting Agile BS (2018) [pdf]
media.defense.gov
DIB Guide: Detecting Agile BS (2018) [pdf]
1–10 of 58 posts
Re: DIB Guide: Detecting Agile BS (2018) [pdf]
#2Great 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.
The real danger is that the project would just be managed badly, independent of professed approach. Just muddling through badly.
(I am not even sure if waterfall was ever actually a thing, I mostly ever only hear about it as a thing to avoid?)
Re: DIB Guide: Detecting Agile BS (2018) [pdf]
#3Great 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.…
> Actually doing 'waterfall' properly would probably be fine?
It's not fine if there is a need for the particular things that agile serves, which is why contracting requirements would specify agile and contractors would, to be response, claim to be agile necessitating the people reviewing the submission to detect agile BS.
Government requires waterfallish process in contracts all the time, but a document on identifying Agile BS isn't addressing those cases.
Re: DIB Guide: Detecting Agile BS (2018) [pdf]
#4Great 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.…
I dont know, the paper that described waterfall used it as an example of what not to do, they covered the better method on the following page but it seems people only read the "headline".
Re: DIB Guide: Detecting Agile BS (2018) [pdf]
#5Great 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.…
I dont know, the paper that described waterfall used it as an example of what not to do, they covered the better method on the following page but it seems people only read the "headline".
Which of course is not an argument in itself against parent's point.
Re: DIB Guide: Detecting Agile BS (2018) [pdf]
#6Discussed at the time: https://news.ycombinator.com/item?id=18910608
Re: DIB Guide: Detecting Agile BS (2018) [pdf]
#7Great 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.…
> Actually doing 'waterfall' properly would probably be fine? Or at least not the bogeyman it's made out to be.
Doing waterfall in the exact sense that is usually described will almost certainly never work well. People usually focus on the design phase, but I think the much more catastrophic part of 'waterfall' is doing testing only once development is complete.
Now, you absolutely can successfully run software projects that are design heavy, that more or less freeze requirements and designs early on, and that seek to execute on the design, instead of iterating. However, if you truly develop for 6 months before any kind of external QA, as described in most Agile talks about what Waterfall means, that is a recipe for disaster. If you do test things by feature, invest in component testing and practice that all along the way, you can succeed.
This essentially describes a 2-stage waterfall: design and execute, where the execute phase includes both development and testing all along the way. Is this 'doing waterfall properly'? Or is it a hybrid methodology? That's a matter of definitions in the end.
It's also important to note that the extent to which this works depends a lot on the project itself. If the requirements are volatile (e.g. when developing a new product with an uncertain market), or if the project is too large (e.g. if the design phase suggests it will take 5 years to finish given the current team), then it's likely that the project would benefit a lot more from an Agile style of development, where you deliver smaller chunks of the project to its end users to gather early feedback on the actual usefullness.
Re: DIB Guide: Detecting Agile BS (2018) [pdf]
#8Great 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.…
> Actually doing 'waterfall' properly would probably be fine? Or at least not the bogeyman it's made out to be. Doing waterfall in the exact sense that is usually described will almost certainly never work well. People usually focus on the design phase, but I think the much more catastrophic part of 'waterfall' is doing testing only once development is complete. Now, you absolutely can successfully run software proje…
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.
You will then read quotes like this, which could have come out of an agile book:
"For some reason what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble."
http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...
Re: DIB Guide: Detecting Agile BS (2018) [pdf]
#9Earlier quoted context omitted.
> Actually doing 'waterfall' properly would probably be fine? Or at least not the bogeyman it's made out to be. Doing waterfall in the exact sense that is usually described will almost certainly never work well. People usually focus on the design phase, but I think the much more catastrophic part of 'waterfall' is doing testing only once development is complete. Now, you absolutely can successfully run software proje…
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…
Yes, basically people never actually seem to be doing 'waterfall' or even aspiring to do so.
I do agree with tsimionescu that leaving testing (and debugging) for last invites trouble.
Btw, that's an excellent paper.
Re: DIB Guide: Detecting Agile BS (2018) [pdf]
#10It started well, then it completely fell on the corporate bullshit side.
For example: "Some current, common tools in use by teams using agile development".
This is the kind of reason why a lot of people are required by management to use useless overkill stacks for their needs like docker or kubernetes.
Also the "questions to ask" are typical ridiculous agile corporate bullshit like "have you a product charter", or common forced process oriented questions.