If I hear that damn mantra again, I'm going to puke. Xtreme Programming had it right
If you aren't writing the damn manual, you aren't delivering an entire dimension of product to your user.
I sat down a little while ago to an old 80's handheld digital business organizer. The device itself was meh.
The manual tho! My God, I'd forgotten what it was like to read a primer on a product that had actually had some effort put into it. People think UX replaces training/SOP's/manuals, and it really doesn't. Your manual is how you mass produce user expertise. Your manual, at least by consumer's opinion is the difference between Yet Another Agile Heap Of Kludged API's and Business Processes and a truly coherent whole.
The problem with most Agile extremists though, is they never take Minimum viable documentation to heart. Or they completely externalize the cost of clear, complete communication to the User. If I had to put my finger on why, it would be because Engineering spends too much time writing and not enough time using their code outside of bench testing.
This isolates from the consequences of poor decisions; and prevents people from facing the One Great Problem of Humanity: Communication.
Keep a bucket handy, because you are going to hear it again, because it often isn't. The fact that a million people are acting entirely contrary to the spirit and text of the agile manifesto, but calling it agile, does not change that.
>> If I hear that damn mantra again ... never take Minimum viable documentation
> But... you're not doing it right. Like, not at all.
Nope, sorry. You can't honestly say someone's doing it wrong, especially when "it" is defined so vaguely, or when "doing it wrong" seems to emerge from the document at least as much as "doing it right," if not more so.
> Where on earth do you get "don't provide user manuals" from the agile manifesto?
Where do you get "provide user manuals" from the agile manifesto"? The problem is that it's most easily read as a rejection of documentation, in general.
> Working software over comprehensive documentation
and use it as a reason not to do documentation at all. It's ambiguous, and can clearly be read as "you should not work on documentation when there is software to work on", and there's always software to work on.
If I hear that damn mantra again, I'm going to puke. Xtreme Programming had it right If you aren't writing the damn manual, you aren't delivering an entire dimension of product to your user.
I sat down a little while ago to an old 80's handheld digital business organizer. The device itself was meh.
The manual tho! My God, I'd forgotten what it was like to read a primer on a product that had actually had some effort put into it. People think UX replaces training/SOP's/manuals, and it really doesn't. Your manual is how you mass produce user expertise. Your manual, at least by consumer's opinion is the difference between Yet Another Agile Heap Of Kludged API's and Business Processes and a truly coherent whole.
The problem with most Agile extremists though, is they never take Minimum viable documentation to heart. Or they completely externalize the cost of clear, complete communication to the User. If I had to put my finger on why, it would be because Engineering spends too much time writing and not enough time using their code outside of bench testing.
This isolates from the consequences of poor decisions; and prevents people from facing the One Great Problem of Humanity: Communication.