41–50 of 58 posts
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…
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:…
The distinction is this: You can't take the CMMI model and execute on it, it lacks sufficient detail. Superficially, if you read the model and try to execute on it you will end up with Waterfall. What you're supposed to do (and why they're making CMMI 2.0) is map your existing processes (or develop new ones) to the model. That is, if you look at the things required for verification it's not complex: you need test cases, test reports, and some other things. It doesn't have to be heavy weight, point out your test scripts and reporting system (CI/CD platforms all have these) and how you maintain them and train people to use them. Done. But if you're not careful, people will write your process per the CMMI model and it's absolutely junk (witnessed in last job, one of the reasons I left).
CMMI 2.0's problem is that it's written as if Agile (Big-A) is the one true God. But it will almost certainly suffer the same implementation issue, it's not a process but people will try to make it one. As such, the resulting processes they do make will be process theater and hinder work, or at best have no effect but to waste some corporate resources. It does lay out a case, better than the previous CMMI model, for picking and choosing parts of the model to implement and get certified on. So that may help a little bit (less all-or-none attitude).
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…
They used an enterprise-grade source control system run by the IT department (Perforce.) It was almost impossible to create a branch. In fact, I saw only one created during my brief 1 year time there.
Since there were no branches, you had "shelve" your changes and get an "in person" code review to merge. If you added something minor, like a new getter, but didn't have a unit test for it, you'd get flagged (even if it was used else where in the code.) It basically took forever to get anything done.
Oh yeah, they never shipped any of this stuff, either.
I could go on...
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.…
If folks remember, one of the seminal Waterfall documents was actually a "Don't do it this way." document[0]. That said, sometimes, Waterfall is the best way to do some projects, but I'd say very, very few. It does work reasonably well for hardware production. Many hardware companies apply Waterfall to software, because it's the process they know. TDD is also a technique that can encourage a "waterfallish" approach,…
And those people will be the first ones six months later to say “you know what? Our stakeholders need Thing X and it’s a top priority.”
My current problem : customers who don't want to participate in the agile process and do want to have a "simple" pre-agreed specification to use to determine project success/failure. Of course they can't write such a spec and want me to do it - and of course I can't without doing large parts of the work to implement it (because if I'm wrong I'm on the hook for a large sum of money wasted).
You can't force customers to "get" Agile. You can force them to understand the risks of not participating in the process.
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:…
All the "boogeyman" activities happen - scope creep goes crazy, testing is run short to hit deadlines set, etc. Like you I never really thought it was a thing until I saw it with my own eyes.
My current problem : customers who don't want to participate in the agile process and do want to have a "simple" pre-agreed specification to use to determine project success/failure. Of course they can't write such a spec and want me to do it - and of course I can't without doing large parts of the work to implement it (because if I'm wrong I'm on the hook for a large sum of money wasted).
Why can't they write it? Conduct a user story workshop, slice out an MVP release, and that's your "spec." You can't force customers to "get" Agile. You can force them to understand the risks of not participating in the process.
Well - yes, this (variations) is what we do, but guess what the outcome is.... "I'm not convinced that we've got this right...", "I was never fully signed up to that...", "I think we have invested a lot of effort in a process that isn't generating business value..."
The problem with Agile is that it doesn't account for politics, if people play nice and are all signed up to get the best done with the tools and people available it's brilliant. If you've got to deal with corporate politics it leaves those with good intent exposed in 100's of ways.
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.…
Our industry really jumped the shark with the Agile and XP nonsense. I flip the bozobit for anyone who uses "kanban", "sprint", liar's poker err planning poker, and other Dilbertspeak non-ironically.
20+ years later, best I can tell, the anti-methodology methodology Agile cargo cult band wagon was for people who couldn't be bothered to sit thru a PMI seminar. The unholy synthesis of pop-biz fashionistas and corporate climbers bouldering along the bullshit jobs facades. Artistes, pointy-haired bosses, "consultants", post dotcom era geek wannabes, and other assorted hangerons and poseurs.
I've always struggled to articulate the core problem. Agile is for those proudly belligerent ignorant people who reject expertise, wisdom, or anything else that would expose their grift.
A cult, more or less.
Buy me a beer sometime and I'll tell y'all how I really feel.
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.…
Software development perspective here, from the receiving end of project management. In my experience, waterfall needs unlimited time and money. Waterfall fails hard when money or time are limited, in which case the likely outcome is that the head of waterfall will be massive and the tail will be rushed, so that one gets a design-heavy and rushed implementation with little or no testing and scant documentation etc. A…
It can be done with waterfall.