What Agile is Not: or at least what it was never meant to be

So do you, like, work at an actual company? One with actual customers and business partners, who need deliverables finished by deadlines that may be months or years out, and who need up-to-date info on whether the project is on track for completion or not? Companies are made or broken, billions earned or lost, because of these schedules and timelines. So the pure jewel version of Agile is incompatible with the business world. Agile is only accepted by business inasmuch as it promises better visibility and control over schedules and costs.

I get that the "pure jewel" version of Agile was some programmers attempting to do the Eric S. Raymond "package our rebellious hacker values in a way that's acceptable by corporate management and subvert the organization from within" thing. But what corporate management found was that it's an ill fit unless adapted to business needs. And even then, what Milt Bryce proved in the frickin' 70s was that for organizational information systems, BDUF actually saves you time and money in the long run. Agile was the standard practice in Bryce's time: almost no planning, analysis, or design, let the programmers do what they want, make changes piecemeal as users got frustrated with the system. His PRIDE methodology (the first software methodology to be marketed as such) was positioned as an alternative and involved lots of analysis and design cycles before a single line of code is written.

Product owner doesn't mean product specialist, nor ticket writer. Having a software engineer who writes tickets (or however work is specified) and prioritises it according to a slightly more distant product manager's needs, but also the software and the team's needs, is a great recipe.

> When agile teams own their process they change it however they need. They are not forced to standardize with everyone else in the organization. And they are not forced to utilize any specific tool. [...] The most terrifying words in the English language are: I am Scrum certified and I am here to help.

Seems like the author is making a distinction between the good "agile" and the bad "Scrum". But that's barking up the wrong tree.

In theory, Scrum allows you to change your process (actually encourages! that's exactly what the retrospectives were meant for). There is no standardization with anyone outside your team in Scrum; and there are no specific tools mentioned in the Scrum Guide.

Yeah, that's the theory... but we all know that in practice, it doesn't work that way...

Ok, but why? To me it seems because typically the management tells you "yeah, the Scrum Guide (assuming they even know that such thing exists, which usually they don't) is just a theory, but in our company we do it our way!"

Now why do you believe that if you tell them "but we want to switch from Scrum to, uhm, a non-Scrum agile", suddenly the same managers will be like: "of course, no problem, let's uninstall Jira and delete all those meetings from the calendar, have fun!"?

When instead they can tell you "sure, feel free to switch to agile... but instead of the way it is described in the Agile Manifesto, we will do it our way... with meetings and Jira! Also, you need to synchronize your agileness with the rest of the company. And we are going to keep the product backlog, but feel free to suggest a better name for it -- something that will sound less 'Scrum' and more 'agile'."

And before you know, you are doing exactly the same thing as before, but everything has a cool new name. The meetings are called "interactions" (because "Individuals and interactions over processes and tools"), backlog grooming is called "customer collaboration" (because "Customer collaboration over contract negotiation"), you have complicated bureaucratic rituals for monthly, quarterly, and yearly "responding to change" (because of "Responding to change over following a plan"), et cetera.

Five years later, we will have everyone complaining about how "agile" was a stupid idea that makes everything worse.