Why Do So Many Programmers Hate Agile?

when talking to programmers, it's not uncommon to notice a definite displeasure or see their eyes roll at the very mention of agile. have you ever wondered why?

what is the cause of their automatic negativity at even the thought of agile development or agile-related practice and method? is it possible, that the things they name as causing the method to fail, are not agile practices at all, but misinterpreted and misused agile values?

it may be, that the team feel as though they're pawns of the scrum master or agile coach.
it's easy to see how this feeling can be created. there is a tendency for the management to bring in either an independent agile consultancy or to hire a scrum master to oversee the agile approach implementation and execution within the team.

the very fact, that this is an outside person, creates a barrier between the team and the agilizing factor , which causes the " us and them " separation.

they may also feel micro-managed and under too much control, especially if each daily stand-up meeting is ended with a talking-to about how little had recently been done — this was never the intended purpose of a daily stand-up.

too strong a time pressure also does harm — teams feel they need to deliver items at regular intervals, rather than when they are all ready and tested — this time-oriented approach can cause quality to suffer.

it's often reported, that the sprints are too short and there is no time to even gather full documentation before writing the code, not to mention looking it over once it is done. so, if working under high time pressure wasn't enough, the developers also need to cope with knowing that really, they only have one shot at getting it right.

it can well be that your programmers hate agile, just because you're making them do it in a wrong way. but it is also possible that you're doing it right, and it's your team that are taking a general dislike to the idea. in which case, all there is left to do is wait for it to grow on the team or replace the team.

people using agile are deciding what to work on, have a say in the product's look and function and gain a lot of control over the project as a whole. it may be worth spelling this out to your employees.

please keep in mind, that agile has been thought out as programming approach by programmers themselves — not project managers.

could it be then, that the main difference between agile as designed and agile as used recently is, that it has become more of a project management domain, rather than programmers'? if so, the only solution might be to take it back from the pms!

while appreciating the reasons why some are not enthusiastic about agile, there is one way of looking at agile, that makes most arguments fail: it is a sign of times .

facts are, that whatever method you choose, in today’s times it will still need to address the ever changing customer demand, and thus following the stakeholders' need to iteratively control the results of your work.

in other words, however you'd like to call it, you will be doing some form of agile development.

and one more thing: it's natural that the unhappy side of any story screams louder. you wouldn't imagine how many developers find agile a working method and don't see anything in it to rage about. but it is always the displeased ones that have more to say, isn't it?

so, try it, customize it (yes, agile manifesto only mentions a few, key guidelines, none of which mention scrum, sprints, daily stand-ups in particular) and only then decide which side of the fence you're on. thanks!