Why Engineers Despise Agile

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:

1. Andy Hunt: The Failure of Agile
2. Michael O. Church: Why “Agile” and especially Scrum are terrible
3. ayasin: Agile Is The New Waterfall
4. 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.