Someone will likely says agile is a lot of shit and someone will reply saying "you are doing it wrong" without giving any indication of how to do it right.
Someone will likely says agile is a lot of shit and someone will reply saying "you are doing it wrong" without giving any indication of how to do it right.
Agile is best thought of as an ecosystem of tools used to shape software (and knowledge) work. Am I "doing it wrong" when I get out my toolbox, use the #2 Philips head screwdriver, but not the torque wrench? NO! Not if I didn't need the torque wrench!
And that's a massive source of pain with "agile", or what I think of as "kitchen sink agile" where the goal becomes, explicit or not, to apply as many processes from as many books as possible – instead of picking just the right ones.
I've literally never been on two teams with the same process needs in my entire (now long) career. Even those teams year-over-year evolve their needs as the members, organization, and business change. Why should the process therefore be a static entity? One of the very few fixed rules I've learned hits to the GP's theme: it's critical to have the least necessary process, just as it's ridiculous to break out every tool in the box just to tighten up a loose screw.
But what agile is or is not is just semantics. It’s irrelevant I think. Who cares if we all follow the same set of rules? People selling certifications that's who!
YES! If you aren't able to hack the process, then you aren't agile. Any rule-book driven "agile" isn't agile.
The problem is, to do agile, you need managers that don't have to have a rule book to follow. Those are rare. If you don't have them, then you get somebody's rigid "agile process", but not much actual agility.