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?”
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!?
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.