TL;DR: Why Engineers Despise Agile
The agile consulting industry repackages an originally human-centered, technology-driven philosophy into a standardized, all-weather project-risk mitigating methodology. Sold to command & control organizations, their middle managers turn “Agile” into a 21. century adoption of Taylorism for knowledge workers. Beyond this meta-level, the reasons, why engineers despise Agile, fall into five categories: Control, manipulation, monitoring, technology and teamwork.
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
Download a Quick Poll to Check Whether Your Organization is Engineer Friendly
You can download a PDF for a quick poll to check the agile health of your organization and determine whether it is engineer friendly or not. If you do so, I would appreciate your feedback on how this worked out for you and what manifestations of agile failure you would complete the list in your eyes.
Cannot see the subscription form?
Please click here
Cannot see the subscription form?
Please click here
The Issues Why Engineers Despise Agile
When I wrote Agile Failure Patterns In Organizations, summarizing typical anti patterns of agile adoptions in organizations, I was surprised to see the traction it received on HN.
So, I started digging more into the topic. Up to then, I had been well aware of the problems that product people are facing concerning “Agile”. You’re dreaming of a Spotify-like place to work for, creating products customers love, while actually you’re being stuck in a sort of Jira-monkey position, churning out user-stories.
From that background, engineers have always appeared to be natural allies for a good cause to me. Why wouldn’t you want to be empowered, doing meaningful work, and having a purpose in your professional life?
Unsurprisingly, there are quite some outspoken critics among engineers. Don’t get me wrong: not all engineers despise Agile. But there are serious concerns being voiced that fall into five categories:
I. Control
The middle management is not willing to give up control to empower teams, thus contributing to the creation of a learning organization. Hence, the agile ideal of transparency and radiating information within the organization ultimately leads to an increase in surveillance.
Read more on the agile micromanagement aspect: Agile Micromanagement in the Era of Autonomy, Mastery and Purpose.
II. Manipulation
The pursuit of personal agendas also drives the employment of external consultants to enforce the middle management’s perspective of the right agile process by sticking to the “rules”—aka: cargo cult Agile.
This approach does not completely ignore the Shu-Ha-Ri principle of learning a new technique:
“The fundamental idea here is that when teaching a concept, you have to tailor the style of teaching to where the learner is in their understanding and that progression follows a common pattern. Early stages of learning focus on concrete steps to imitate, the focus then shifts to understanding principles and finally into self-directed innovation.“.
It rather starts with applying the “rules” by the book in phase one and then conveniently sticks to them, ignoring phases two and three. And by doing so, the skeleton Agile is turned into yet another management style that advocates following a plan—just in shorter intervals, called sprints.
III. Monitoring
Agile mechanics are adopted whenever beneficial, but the culture itself is not changed. In the case of transparency and metrics, the new level of information leads to monitoring, and ultimately to micro-management. This way, transparency backfires, creating vulnerability instead of opportunity.
The all-important metrics of Agile are story points and velocity, and Jira acts as the manifestation of the resulting bureaucratic overhead: have a ticket for each and everything to make every engineer’s performance visible.
By making the “tech” visible for non-technical people, it enables those to gain a sort of managerial control over territory that they could not exercise before.
Built on top of this are forced commitments without having the authority to actually make them happen. Principles like team empowerment, leading by OKRs, and service leadership thus become lip-services, while micro-management rules.
IV. Technology
Agile fails to deliver–as promised by the Agile Manifesto–an engineering-driven development. Decisions are still business-driven, made by people without an understanding of technology. That includes in most cases the product owner as well as the middle management, or business analysts.
Agile also makes technical debt inevitable, as teams need to deliver each sprint, preferably in a way that commitment matches velocity to make planning and risk mitigation easier for the management.
V. Teamwork
There is no room for the individual in Agile. It does not respect seniority and personal growth of the individual engineer, as there are no longer tech leads.
Instead of “individuals & interactions over processes & tools”, Agile turns individual developers again into cogs of the machinery, making the disposable clones within a more or less anonymous process. Which is also the rationale behind shuffling team-members around upon short notice.
All this contributes to a loss of ownership: a project is just a list of tasks provided by business-people, split among consecutive time-boxes, aka sprints or iterations. Which is the reason why projects become hard to be passionate about?
Despite all loss of ownership, team members are nevertheless expected to participate actively in ceremonies: from time-consuming standups and backlog refinements to retrospectives, a sprint-based “self-improvement” ritual.
What Are Your Thoughts?
Can you teach an old (management) dog, socialized in a command & control environment, new agile tricks?
To begin with, I believe there is Catch 22: a “good manager” by traditional standards is defined by knowing what to do and how to solve a problem.
Now, what if a new idea requires precisely the opposite by admitting she doesn’t know? What if it is about embracing learning, experimentation, and failure and empowering teams to figure out the solution, but not to deliver it yourself?
So, are we stuck in cargo cult agile for all eternity? Or will it pass all others like other management fads, too? Or shall will we be able to turn the ship around?
Personally, I still believe in George S. Patton’s “Don’t tell people how to do things, tell them what to do and let them surprise you with their results.” approach.
What are your thoughts?
Further Reading
If you like to dig deeper into the issues why engineers despise Agile, I recommend the following posts and videos as a starting point:
- Andy Hunt: The Failure of Agile
- Michael O. Church: Why “Agile” and especially Scrum are terrible
- ayasin: Agile Is The New Waterfall
- Harry Harrold, Rupert Redington: Agile Apocrypha and an Ad-hoc Manifesto
Related Posts
Agile Failure Patterns In Organizations
Why Agile Turns into Micromanagement
Hiring: 38 Scrum Master Interview Questions To Avoid Agile Imposters
📅 Scrum Training Classes, Workshops, and Events
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
The whole post is a summary of often cited articles from developers on the notion that “Agile” is abusive. The articles listed under “Further Reading” are most often referred to. I believe, too, that the notion expressed by these authors is not valid, and that they indeed confuse agile practices with Scrum.
The subject and lots of the contents of this article are misleading. It feels like the term Agile is used where Scrum is actually meant. Agile is a way of thinking, a culture if you like, and it’s all about delivering working software as often as possible in a flexible way. There are no such things as two-week sprints in Agile. That’s Scrum you’re talking about. That goes for a lot of stuff said in the article. The “Further Reading” articles also contain the same mix-ups. Agile != Scrum.
Well put, Meghana! 🙂
I am an engineer, practicing Agile for several years now and I do not despise Agile. My company has been successful in sustaining a multi-tiered Enterprise Agile environment in which:
1. Line managers are simply that. They do not influence the delivery teams.
2. Team boundaries are the people. Work is moved to people, teams are not re-organized to fit the work.
3. Predictability comes from stable teams. Story points and velocity have no meaning if teams change over time.
4. Shared understanding leads to ownership not the loss of it.
5. Retrospectives are much more than a ritual. If there is only one Scrum ceremony that I can use, I’d choose the retrospective. When done right, this brings out the good and also the dysfunction in the team.
I dug further into the agile micromanagement aspect, see: https://age-of-product.com/agile-micromanagement/
Everyone has their own version of what “Agile” means to them. For some, it’s not much different than waterfall with a kanban chart. For others, it’s pair programming and writing unit tests all day. I think deep down agile tries to have everyone one the same page at all times while avoiding wasting time.