(Hmm. The author says "Follow Scrum, Lean / Kanban, or eXtreme Programming to the letter, and let your team focus on the product."
I disagree - quite vehmently. I guess that's obvious, given that I'm calling out the various capital-A agile methodoliges, and the parasitical industry around them, as harmful/bloated/mostly pointless. But how did you figure out I hadn't read the blog post from that? Now I have, I just think he's wrong).
The author pretty clearly states that Agile works well and we should stick to it without deviating too much with our own processes. Your point was related to the parent post but contradicting the article and didn’t acknowledge the contradiction or why your opinion about Agile might be more correct than the author - that’s basically it.
The industry around it makes total sense - often bloated and misusing terms, but the process itself can work well as a starting point. I get the impression many engineers never attempt it because of bad experiences named Agile sometimes. Understandable of course.
Even you disagree with the author :) But yeah, a team with the power to change its own processes, rather than have Agile imposed on it, isn't a team that's cargo-culting an Agile Brand).
(Last couple of months I've been introduced to "retrospective story points"; we're supposed to fill in how many points the ticket actually took after we've done it. I haven't yet found the words to express how pointless I think this is).
That's the thing... Agile processes do position themselves as a starting point, and suggest that once the team understands it by living it (but not sooner!) they might adapt it and customize it.
From The Art of Agile Development, 2nd Edition by James Shore et al. (the most recent eXtreme Programming book, if you will):
> As a result, although it’s tempting to customize your Agile method from the beginning, it’s best to start with a by-the-book approach. The practices that are the least familiar are the ones that are most tempting to cut, but they’re the ones you need most, if you’re really going to be Agile. They’re the ones that involve the biggest change in philosophy.
> Mastering the art of Agile development requires real-world experience using a specific, well-defined Agile method. Start with a by-the-book approach. Put it into practice—the whole thing—and spend several months refining your usage and understanding why it works. Then customize. Choose one of the rough edges, make an educated guess about what happens, and repeat.
From The Scrum Book by Jeff Sutherland et al.:
> It’s important to understand the rules, and it’s even useful to follow them most of the time. But reading the rulebook of chess won’t make you a great chess player. After learning the rules, the player then learns about common strategies for the game; the player may also learn basic techniques at this level. Next is learning how to combine strategies you learn from others while maybe adding some of your own. Ultimately, one can transcend any formalism and proceed from the cues one receives from one’s center, from one’s instinct. [...]
> Some day, long from now, you may even outgrow these patterns as you evolve them and define your own. There are no points for doing Scrum, and these patterns are the gate through which a highly driven team passes on the road to the top echelons of performance.
But have you tried any of that, in a team that has had "follow Agile to the letter" imposed upon it? I'm trying to distinguish between the Manifesto and the Industry here.
