Someone questioned me, “Why do Devs hate Agile?” As I worked through my response, I thought it was worth writing down. There are 3 reasons I can think of, but before we get to them…
Firstly, I do not think all “developers do hate Agile.” Or somewhat, I do not think the wide majority of them hate it, and hate, of course, is a very big word. Some do, no doubt, but all? A blanket “all developers hate”? No.
Suggested read: Top 5 agile methodology myths
I do think it is trendy to slag Agile off, and little do this better than the Agile community themselves. And inappropriately, like a lot of trends, once it gets started it catches on. Once developer X says “I don’t like Agile” then developer Y thinks it is cool to say it, too, and developer Z sees X and Y doing it, so joins in.
The strong thing about all this is that Agile is the product of programmers. In the starting it was developers, like me, who proverb that the classical manner of doing things (note down what the user wants, plan it, code it, etc.) did not work very good, but seen that the manner most work actually occurs (quick, code foo… Oh, foo is not quite right, modify it, quick) was really better.
Reason 1: Agile Is Now an Imposed Variation
As per my knowledge, developers wish to work Agile because true Agile enables them to do a quality job. Agile does not bring half the advantages it promises if organizations don’t pay focus to quality. That is what we used to call technical brilliance; it means programmers doing work that they are proud of.
Specifically “technical methods from XP,” explicitly: easy design, unyielding refactoring, test-based development (plus behavior-oriented development), pair development, and things like face-to-face discussions and “story is a placeholder for a discussion.”
I will point the finger exactly at Scrum, and then Kanban, for not mandating these methodologies — something I did with Xanpan.
Also read: How an agile roadmap will help your project
Without these methodologies, teams are determined harder to deliver something sooner and quality drops. As quality droplets, it gets more problematic to bring anything in a short amount of time. Therefore, more is required of coders, stress and tension rise, and it is not fun.
Reason 2: Agile Without Technical Quality Creates Developers’ Lives So Much Poorer
I reminisce meeting some developers in Cambridge, and almost the very first thing they told me was, “We do not like Agile; our superiors went on a Scrum course and have contended we do it for months.”
I hastily discovered that they were not doing any technical processes, and as an outcome, they were racking up more and more technical responsibilities and making their own lives difficult. Once I clarified that they were missing the technical processes, their attitude modified.
Now to the last reason, perhaps the big reason…
Reason 3: In the Incorrect Hands, the Same Agile Tools Are Very Operative Micromanagement Tools
The Agile toolset is envisioned to help teams manage themselves; it is envisioned to create problems visible so they can be spoken and fixed. In the hands of people with the correct attitude, this is bright.
But… the same tools used by someone with the incorrect attitude are a micromanager’s dream.
Featured article: Agile project management
Which micro-managers would not want everyone to stretch a status report at 9:00 am every day? Who would not wish to see all work wrecked down to pieces for which NAMED personal could be held accountable? And why would not they wish to make a surprised face and send a very clear “that is not suitable” message every time an assessment was high?
Prominence becomes a tool of blame.
I once facilitated a team at an airline set up a Kanban board, and in its place of using it to see issues, errors, and find opportunities to advance, the managers concerned used it to giving blame, point fingers, and prove that nothing was happening because someone else was not doing their work. Not Agile.