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.
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.
