There's a lot to take offense to in this article and I wonder if the author has any practical experience with working within agile constraints or if he just pic

There's a lot to take offense to in this article and I wonder if the author has any practical experience with working within agile constraints or if he just picked up a book and didn't like it. For example, "In theory, developers are supposed to be interchangeable in agile/scrum". I've never seen that articulated in any agile literature. To the contrary, the agile manifesto puts "individuals and interactions" on, literally, its first line. It's ALL about people and finding ways for people to contribute to delivering working software. Processes at their best are self-imposed sets of constraints that are empirically found to lead to better software (for whatever axes of 'better' makes sense for your team - faster, feature richer, higher quality, etc.) Scrum gives you a baseline set of rules to abide by. Any team who've worked with Scrum for more than a few months will start to tweak, add to or remove from these rules. If they're any good, they'll measure their tweaking and see what works and what doesn't. This is the whole point of having a retrospective. As another example, if you want to include quantifiable performance bounds in your stories, do so. We work Scrum-ish, and we have a set of QA steps for every story implicit in its delivery (works across supported browsers, feels fast, immune to common security errors, etc). We test for this, and we demo it, but it's not articulated in every story. It's implicit in our work.