Pentagon advised to get agile if it wants to keep up with evolving threats The US Government Accountability Office (GAO) is recommending the Pentagon respond better to evolving threats, such as speeding up software modernization by using agile dev practices. According to the congressional watchdog, the Department of Defense's reaction time will be increasingly determined by how swiftly it can develop …
1. It has to be strongly-supported from the top down.
2. Pre-existing data which needs to be converted is one of Agile's bugaboos. Each time a "story" is added which needs new fields, the existing datasets need to be converted, again. If there is a "database", vs the data (still) living as sequential files on 9-track reel-to-reel tapes. For a Univac 1108. (Governments still tend to have a fair amount of that sort of thing.)
Never happens.
It did happen, once: the Chrysler Comprehensive Compensation (C3) project was a long-term project to rewrite Chrysler's payroll application, and was generally deemed a great success.
But about 99.9% of the time, that from-the-top support does not happen.
This post has been deleted by its author
Quote: "...difficult to modify requirements during the development process..."
So..............
(1) Agile #1: User stories on the wall
(2) Agile #2: Pick a few user stories for sprint #1
(3) Agile #3: Deliver sprint #1 (Note: not even close to what the users want)
(4) Agile #4: Pick a few more user stories for sprint #2
(5) Agile #5: Deliver sprint #2 (Note: not even close to what the users want)
(6) Agile #6: Users decide to add more user stories.....but they conflict with the first two sprint deliveries
(7) Agile #7: Redo the deliveries of sprint #1 and sprint #2
(8) Agile #8: Dev team don't know what they should be testing
(9) Agile #9: Users don't know what the DevOps team have delivered
(10) Agile #10: Product Owner is fired......start again at Agile #1....but with a DIFFERENT set of user stories
(11) Agile #11: ...and so it goes......
Yup.....Agile, scrum, product owner, devops.............and of course, writing a requirements document is SO...O.....O.....O twentieth century......
Quite.
The biggest bugbear of software development has always been the failure to properly identify the requirements. You need to have a sufficient grasp of the requirements before you start making fundamental decisions about data structures and storage, performance and scaling. All forms of project management can deal with modest changes to functional requirements. No form of project management can take a fundamental change of architecture in its stride or compensate for a fundamental misunderstanding of the problem.
Overselling "flexibility" contributes to a lot of these user "stories" being fiction - if people are told they can fix things later, they won't bother even to try to get it right first time. And hardly anyone can be bothered to do the user-acceptance testing at the end to check the stories have a happy ending. Never mind the fact that the development costs never end as "refactoring" is eternal.
Many projects end in failure due to human politics and political structures. Everyone in power wants to have their special requirement included, which frequently leads to mutually-contradictory requirements. Lacking someone(s) with knowledge, wisdom, and power to cut through the bullshit, you end up with products (equipment, computer programs) which do many things, yet do them badly.
Enough "compromise" can, metaphorically speaking, turn a gold nugget into a shit nugget.
If it's miitary equipment, you end up with things like a musket which has a broadaxe blade on the other end (which the soldier is expected to press firmly to their shoulder before they fire the musket).
If it's computer applications, you end up with conceptually-vague programs which are a collection of semi-random features and capabilities, with the resultant, justified, user hatred for that program, and with a code-maintenance nightmare.
No methodology, "agile" or not, will succeed under such malconditions.
Agile has always struck me as the systems version of the Double Fudge Sunday diet. Just eat your normal meals and supplement them with a double fudge sundae every afternoon and the pounds will just melt away.
Anyway, my experience with military systems was that design, implementation, and test was extraordinarily difficult and complex and that the associated logistics, training, and support was really, really hard. Further, for many systems, getting things wrong was bad. Perhaps very bad.
For a brief vision of what can go wrong, try Arthur C Clarke's short story Superiority. https://www.baen.com/Chapters/1439133476/1439133476___5.htm
Being an embedded sort I never had the luxury of having a large -- or even quite small -- team to work on a project. But I have had to work with applications programmers who talk about Agile and Scrums and what-have-you. They always seemed to be late with their contribution -- its always "very complicated" -- and their offerings invariably had missing features and undiscovered bugs. I put it down to them confusing 'programming' with 'filling in the blanks in a GUI template'. This lead to an unhealthy reliance on third party libraries (all with their own idiosyncrasies, of course) and the general expectation that if something complicated was needed we'd provide the library.
(...or, in short, if we wrote the application they'd put a GUI around it)
In case you think I'm being unfair with this single example it wasn't just one instance that turned me off -- literally every company, every project, was infested wit this mindset. Which combined with a general attitude towards use crude mechanicals (who can't write code, of course -- at least not proper code) let to a rather poor taste in one's mouth. So every time I hear words like "Agile" I tend to translate them into "We're Screwed".
The Agile manifesto was spot on. Listen to the fucking customer and give him/her what s/he wants.
What happened... That scrum et al bollox.
Add in the military and OMG. When you work on a military project, the point is that you only know as much as you >>need to know<<.
It's called compartmentalisation, so sticking post-it notes on a board or e-board for everyone to read is a bit of a no no.
int main(enter the void)... The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
