The Issues Why Engineers Despise Agile
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, when actually you’re 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:
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.
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.
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.
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, preferable in a way that commitment matches velocity to make planning and risk mitigation easier for the management.
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 and interactions over processes and 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.
Check if Your Organization is Agile and Engineer Friendly
You can download the required quick poll (PDF) on the agile health of your organization, print and use them for yourself. If you do so, I would appreciate your feedback on how this worked out for you and what manifestations you would add to the list.
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 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 other 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?
If you like to dig deeper into the issues why engineers despise Agile, I recommend the following posts and videos as a starting point: