Agile strikes me as … the same thing as everything else: Good until it’s mis-applied, usually by taking it to an extreme…
Much like how Object Oriented Programming gets flak from some, Agile has many ways to abuse the concept. That does NOT make it a bad idea over all, it just means it’s not a magic silver bullet.
Hint: There are no silver bullets. Let alone magic silver bullets.
One of the bullet points of agile as I understand it is “do less documentation”. My previous boss was big on agile, and we were already barely documenting anything, so…
Yea… That’s definitely one of the dumber points of Agile. Only wise if you’re writjng too much as is.
That was my assumption, too. He also liked to seize on the idea that every sprint must produce something useable… Which I take to mean “give your client something to poke at and test, not a diagram” and he took to mean “every sprint must produce something useful to the client, that they can immediately put into production”.
I mean, where else is a customer going to poke at a new feature but production? Can save even more time by doing all the testing there! Such a wise manager …
yep and 268% is a oddly specific number
Well that part can be totally fine. It is absolutely in no way what so ever an indication of something fishy if they’re giving the data and procedure they computed the number with.
Statistics can and often do produce specific numbers. Who knew!?
Well there’s agile and then there’s agile…
What percentage of places that claim to be agile have even a single decision maker that has read the agile manifesto?
I’m going to say, generously, 3%.
I like to tell new hires : “we claim to do agile but we really don’t… Like everybody else”
If your method of development requires reading a manifesto go fuck yourself.
I actually don’t think I disagree with you in principle. I had the chance to talk shop with Kent Beck, and honestly, I don’t think he would either.
Honestly, I can sum it up pretty succinctly:
“Use some common fucking sense”
I don’t think you should HAVE to read that. But, I’m routinely disappointed.
So, I love the Agile Manifesto, because instead of saying “Use your fucking head” to my managers who claim to be agile, I can much more diplomatically say “What does the agile manifesto say about that?”
They say knowing the requirements before you start loads to a higher chance of success. Agile projects are more likely to fail because you’re more likely to use Agile when you don’t have a clear map of the requirements and want to be able to pivot quickly. Working as intended I would think.
All that is assuming your shop actually knows what Agile means and isn’t just doing Waterfall with stand-ups.
Yeah they seem to be implying that the “opposite” of agile is getting a good set of requirements, which is… optimistic.
This is the best summary I could come up with:
Even though the research commissioned by consultancy Engprax could be seen as a thinly veiled plug for Impact Engineering methodology, it feeds into the suspicion that the Agile Manifesto might not be all it’s cracked up to be.
One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed.
“Our research has shown that what matters when it comes to delivering high-quality software on time and within budget is a robust requirements engineering process and having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout.”
A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.
One Agile developer criticized the daily stand-up element, describing it to The Register as “a feast of regurgitation.”
In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.
The original article contains 501 words, the summary contains 175 words. Saved 65%. I’m a bot and I’m open source!
Right. Because you start early, get an mvp into market and see what works. If nothing works, you should have spent the bare minimum time and money getting there. But if it succeeds, you are there long before waterfall. Collecting market share and metrics.
That’s the dream, at least.
“One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed.”
I want to know the specifics of how we got to the point where the statement above needs studies to validate it and how this has become news for anyone.
As the real gurus of Agile point-out,
most of the nuveau methods/processes were ideological,
but agile had engineering-requirements, too ( test-1st develoopment, e.g. )
Which makes it much superior to all the ideology-but-no-engineering-hardening methods.
As they also pointed-out, you NEED disciplined individuals & teams to make it work.
IF you don’t have effective & driven-by-quality/integrity-of-work teams, agile isn’t the right method for you.
I’d go further:
I’d say that both waterfall & agile ( Wysocki’s book on project-management identifies that Traditional is the poorest match for reality, Agile’s best, & Extreme is research whereas Emertxe is where you’ve got a solution, but don’t know what it’s for, yet ( like Post-it notes glue, before sticky-notes were invented ) )
both waterfall & agile are mis-apprehensions of what’s required.
Until you understand the required architecture, you can’t make the right architecture-choices, right?
So, why not make a prototype agilely, until one has a proper domain-model, an executable toy-prototype which demonstrates all the key functions, & then when you’ve got the working, executable model, then you understand the architecture required, and only then do you switch from agile-prototyping to building-out the real, hardened thing…
Just seems sane, to me, but I’m just some idiot with a bit of thinking, not a working … anything, really.
