I feel that what the author has described is the very opposite of agile.<p>This article has some fair points on bloated companies, useless meetings and rituals, guesswork-based products, and I wouldn't dare to estimate how many companies could fit into this description, but agile proposes just the opposite (I'd call that "conscious agile").<p>Even if you read the Scrum guide, you'll see that it does not prescribe most of the things that are commonly attributed to it. Many of these canned practices come from taking things out of context, or from a misunderstanding of the reasoning behind the Agile or Scrum principles.
I get what the author is saying, but I feel like many of the examples provided have more to do with poor culture and chronic mismanagement rather than issues with “agile” itself.<p>However, I don't believe Agile is the root cause of tech laziness. No framework encourages underestimating capacity or wasting time on distractions like “TikTok smoothies”. This issue stems from people and performance problems, which would likely exist regardless of the planning framework.<p>Before adopting Agile, I experienced the need to justify financial spending on Waterfall plans for non-existent hires/teams, two years in advance. With quarterly agile planning cycles and static teams, we spent significantly less time worrying about whether we’d get people at all, and more time looking at the teams' overall velocity and outcomes.<p>I wouldn’t have been able to do any of that without the estimations and structure that the author despises.<p>The reality is, in larger companies, teams don’t exist in a bubble. They need to justify their outcomes, plans, and velocities, or they get laughed out of the room by finance and budgets slashed. Frameworks around agile (SAFe/etc) give tools that help management to forecast and finance investments into their teams. If I didn’t have estimations and velocity, and a way to break down and visualise work,<p>I don’t get what the author suggests the alternative is. I’m sure some teams have full autonomy and trust to do whatever they want without oversight by finance and PMO, but my experience is that is few and far between (or small enough where the team and upper management are one and the same).<p>While I've encountered my fair share of subpar Agile implementations, it doesn't mean we should abandon the concept altogether. The widespread adoption of Agile suggests a genuine need for improved working methodologies.<p>Instead of advocating for Agile's downfall, let's acknowledge the necessity of tools for sharing roadmaps, streamlining transitions between teams, and assisting management in making data-driven investment decisions. By doing so, we can collaboratively refine and adapt Agile methodologies to better meet the evolving needs of contemporary organisations.
Developers dont like agile for two reasons.<p>One is a valid criticism of the implementation of agile. 80% of all companies "doing agile" don't want to give up their traditional command and control so they never meet what the agile manifesto intends. Which is to reduce the overhead of projects and let the people doing the work make the decisions.<p>The second reason developers dont like agile is because some developers have this lone wolf attitude to development. They don't want to have to communicate and compromise with others on their work. They want to be given a project and left alone until its done. This type of development is not great for the business because there is no transparency into if the work being done is work the company needs done. And no feedback for developers if what they have created is correct until its completed.<p>Communicate and trust are what make great teams work. Bad implementations of agile are a lack of trust. Developers hiding away creates a lack of communication.<p>Agile should be a north star of what a team aims to achieve and not a religion to be followed without question.