Re: Agile isn't nebulous
"The thing is, argue against the statement?"
Sure. Let's try that.
"Would your customers prefer exquisite documentation about the project and the code base, or actual working software?"
Both, usually. In a project where documentation is weighted as heavily, then things take longer, but the documentation matches. Compared to the many projects I've seen where the documentation has problems, that is usually better. What happens there is that documentation is patchy, sometimes out of date, and you get more support requests. That's taking up your time and theirs because the docs were incorrect or missing. If I leave a job with documentation in place, someone can pick it up later. If I leave with patchy docs, they will either read those and come to hate me the second or third time the code doesn't match what they read or will have to call me to ask for help.
"Would your customer prefer working software now, with continual updates to improve it, or wait a lot longer and then have to wait another lengthy period for any changes?"
This one is easy: yes, they would prefer the agile method in most cases. However, I generally wouldn't. If the customer wants something, they should mention it at the start so I can plan for it. If they request a change 80% of the way through their original request which requires a redesign, they've wasted a bunch of my time. If they don't care how long I spend working on it and they pay me for it, that's fine with me. They do care about both things, so it's not. I'm fine with change requests that are minor, but nontechnical people rarely understand what is a minor change and what is massive.
"Would you adopt a development methodology that doesn't support changing requirements, even late in development? Have you ever had the luxury of an implementation project that didn't have those?"
Of course not. However, my methodology is to try to gather enough information so that there are likely to be few major changes at the end, not to embrace the chaos and let anybody change whatever they want.
"They're not vague statements, they're basic positions and principles."
Which get constantly redefined and which don't actually tell you anything.
"They're not prescriptive, they trust you to be a professional and take ownership of your own methodology. They don't tell you to do this or that, they encourage a mindset."
They encourage a mindset of basic platitudes. "Trust [the workers] and give them what they need" isn't original and it doesn't tell people anything. It's like telling people to be nice; it's better if they are, but exactly how that gets implemented and what benefits it brings need more elucidation.
"the Agile Manifesto merely articulates the approach that a very large group of experienced professionals have found to be the most effective."
Except the only thing I can understand clearly from their proposal is "accept change all the time". Everything else has multiple possible meanings.
"Disclosure: I've successfully delivered software into a production environment at a bank using Extreme Programming, and worked in and alongside teams using agile methods and methodologies for two decades. They deliver."
And I work on an agile team as well. It's fine. If we're actually agile, though how could I know? Our documentation does have the patchy problem, so maybe that's a good sign.
I think a lot of companies that do internal coding already did a lot of the agile process. Probably less in contracting or consulting, though I am young enough that I haven't seen a lot of what things were like before the manifesto. Accepting change didn't have to be written into the requirements if managers were still demanding things get changed, and knowing managers like I do, I don't think they just started doing that.
Biting the hand that feeds IT
