I agree that agile methodologies are a whole lot of bullshit, but the problem really is cargo cult.
Most people working in software are juniors, and that includes most managers. The fact that they have a title of "VP operations" 2 years after graduating does not magically make them experienced. What do they do then? They read books about "how to lead a team", and they blindly apply what they find there.
Because they have no clue. Many times they have not even had a team lead in there professional career themselves: they jumped right into management. And of course their team of junior developers (with high titles that don't make them experienced either) don't know better. So it ends up in a big cargo cult. Which sucks.
Wonder how 'Sprint', 'Scrum', 'Kanban' etc. all evolved out this? I really can't understand how it went from 'individuals and interactions over processes and tools' became formalized processes of daily standups, 2-week sprints, etc.
Scrum came from a world where product folks and developers never directly talked to each other. Everything was a formal written request with some requirements and there were SLAs for how long developers could look at it before providing questions and estimates back. After one (two if you're lucky) round(s) of questions a deadline is established, and work begins.
In that world, creating a single product owner that had the full complete say of this is what will happen that met with developers on a daily basis is a huge improvement of individuals and interactions. This is the single biggest win of Scrum, getting people to just talk to each other regularly, by having mandatory meetings all the time. If an organization has good communication or a product is too large for a single person to manage, Scrum ceases to be as useful option.
Kanban came from elsewhere. The word comes from post-war Japanese car factories, but the principle is older. Kanban boards were physical boards, with tokens representing various machines' or workers' availability, and the presence of things to work on. It's more a work-scheduling mechanism for known, understandable, repeatable work.
Interesting to know - thanks for the info. Strange to think that something designed for 'known, understandable, repeatable work' got adopted by software development.
Some software-related work, like regular changes to a website, or regular SRE work, is understandable and relatively repeatable.
Software development work usually isn't. Software development, by its nature, automates away everything repeatable and predictable, so unpredictable and never-before-seen stuff dominates.
Manifesto came out in 2001, you need to take into account the context of that time - the processes were often much more heavy-handed (esp. in big companies) than they are now. This manifesto item was never about not creating any processes.
I’ve said that many times over the years. The irrational mimicking of what others are doing created this Frankenstein model of working that proliferated over the industry.
And they self reinforce themselves in their biases. As long they say it's an epic and have a burndown chart they feel good. Nothing works, information is lost, quality and velocity is low, but we're very much agile.
Most people working in software are juniors, and that includes most managers. The fact that they have a title of "VP operations" 2 years after graduating does not magically make them experienced. What do they do then? They read books about "how to lead a team", and they blindly apply what they find there.
Because they have no clue. Many times they have not even had a team lead in there professional career themselves: they jumped right into management. And of course their team of junior developers (with high titles that don't make them experienced either) don't know better. So it ends up in a big cargo cult. Which sucks.