
In a nutshell, why do a lot of developers dislike Agile? - programminggeek
http://brianknapp.me/developers-dislike-agile/
======
chrisbennet
When _developers_ are the one doing agile-ing, it seems to more successful.
When it's a process driven by/for management it can get frozen in place making
change harder.

Developer driven:

Mike: "Bob, I'm skipping scrum today."

Bob: "K" (Thinks "He's still working on the gnarly multithreading problem.")

Management driven:

Manager/Scrum Master: "Bob, where's Mike?"

Bob: "He's deep in flow working on that multithreading problem."

Manager: "Go get him, he can work on that later." (Thinks "I have boxes to
fill in my spreadsheet. How can I do that without a scrum meeting??")

------
eesmith
I dislike Agile because apparently the only thing is "waterfall" or "Agile".
Many seem to think that before "Agile" or at least "Extreme Programming" there
was nothing but the waterfall boogie-man.

It's as if they had never read books like "Rapid Development" which describes
over a dozen different design approaches, with pros and cons.

I dislike Agile because apparently the only important thing is the Toyota Way.
They never mention alternatives like the Volvo's Uddevalla plant and
humanistic manufacturing.

Eg, quoting from [http://gerpisa.org/ancien-
gerpisa/actes/9/9-5.pdf](http://gerpisa.org/ancien-gerpisa/actes/9/9-5.pdf)
"After a slow start Uddevalla took off and in 1991 reached the level of the
Gothenburg mass production plant. From the last quarter of 1990 to the last
quarter of 1992 Uddevalla cut the assembly time at an average rate of one hour
a month. This rapid learning curve surpassed developments at the Gothenburg
plant, where lean production techniques were introduced to boost performance."

Yes, such conclusions are contested, but it's still a concrete alternative
that's almost ignored by those repeating the chant "Toyota ... Toyota ...
Toyota."

I dislike Agile because it's a collection of ill-defined mush. If a group
adapts or changes in any way during a project, and the project is successful,
then it's counted as an Agile success story, while if it project fails despite
flexibility then it must not have been True Agile, or at least Enough Agile.

~~~
Clubber
"Rapid Development" was/is one of my all time favorite "project management"
type books. Waterfall is a baseline. Even in what people would consider
waterfall, there were "buffer" items incase we needed to change everything.
The scrum disciples are being disingenuous when they compare everything to
waterfall. It's like comparing the newest language to programming the Altair.

------
trentnix
Because few organizations actually enable real Agile development. I did some
"Agile coaching" in a previous life and time and time again I'd see teams
embrace the cosmetic parts of Agile - daily standups, iterations,
retrospectives - but workflow was still much the same as it always was.

Agile, done right, is more about how work is broken down into consumables and
deliverables. It's about clear prioritization and freedom to focus on the task
at hand. But most development teams would iterate aimlessly, while the
organization around them continued doing business as usual.

To successfully embrace Agile, the entire organization has to do so at some
level or another. You have to break requirements down into pieces that can be
consumed in an iteration. You have to prioritize clearly. And you can't change
priorities until the iteration is complete.

Additionally, many software teams misunderstand how they work. I can't tell
you how many times a team would insist to me they were using a waterfall
process, but when I asked them to describe the previous workday they'd
describe end-to-end firefighting. When I would introduce Agile and the
controls that it brings, they would react negatively expecting that Agile was
some magical organized free-for-all.

Additionally, lots of consultants made money off of the promise of Agile and
the cult of Agile. They didn't provide practical solutions, and organizations
resisted change. So much of the indigestion that developers have regarding
Agile is due to their own experiences with organizations that bought the
promise of Agile but didn't do the necessary work to make it successful.

~~~
Tomis02
> real Agile

Heh, classic response. Whenever your project fails, your coach tells you it's
your fault because you didn't do real Agile. Same with OOP, whenever your code
inevitably becomes a tangled mess of classes, you will have all sorts of gurus
making metric shit tons of money from books and consulting telling you you
didn't do real OOP.

Guys, please, can you just admit there is no recipe for success (rhetorical
question, of course you can't, that's where you money comes from, maybe you
even believe your own bullshit)? There is no real Agile and OOP and other crap
that I forget, they're just buzzwords that, when applied long or hard enough,
produce shit. If you had kept you project to an absolute minimal level of
Agile and OOP, it would probably still be alive and kicking. But you didn't,
because you jumped on the bandwagon, you used religiously whatever was
popular.

> Agile, done right ...

Yeah, heard that a thousand times before. Sadly, younger developers fall for
this all the time, so shit grows exponentially. I'm aware my opinion has
always been in minority but whatever.

~~~
mavelikara
How does one do "real OOP"? Or "real FP"?

~~~
Tomis02
I don't know how one does real OOP, but I know what C++ OOP looks like when
used long enough.

1) Architecture. Architecture trumps everything. Even though "favor
composition over inheritance" has been repeated for a very long time, some
people just didn't get the memo, and you'll encounter mind-boggling
inheritance hierarchies (sometimes even template inheritance, to make it fun)
with more levels than circles of hell.

2) Class-itis. Everything must be a class, and free-floating functions are
seen as coming straight from The call of Cthulhu. Most people are more
concerned with the way the class will look and fit in the existing
architecture than if the desired functionality is achieved.

3) Code reuse mania. If you write the same line of code in two different
places, some people's palms start sweating. More than two identical lines in
two different places and you'll have people screaming to move the coded to
another place and share it, irrespective of whether it is beneficial or not.

4) God objects. When people just can't take it anymore and simply jam yet
another object in the God object. Yes, I know a lot of people from the cult of
OOP will tell you this is an anti-pattern, and I agree, but it happens. And
when they unravel the God object, an even bigger mess emerges most of the
time.

I don't know, I'm probably forgetting a dozen other manifestations of OOP.

You know what "you're not doing real Agile/OOP" sounds like? "You're not doing
real communism". And we never will.

------
api
Agile often allows no time for doing it right, leading to high levels of
technical debt. In the end it leads to Rube Goldberg machines and the "big
ball of mud." It's suitable for prototyping but often fails for producing
quality software.

The nastiest balls of glued together snot I have ever seen were almost all
from textbook Scrum shops. The rest were from lowest bidder outsourcers that
probably use similar management methods to try to get code from bad or
underpaid/unmotivated coders.

The problem is that deep conceptual thought about a design and deep
refactoring are hard to capture as a ticket item. Quality is something that
perfuses all deliverables but is not itself a deliverable.

Agile is also totally unsuited for innovation. You will never get a Xerox Parc
or SRI with agile. You can only make what you already know to make with agile.

~~~
kwhitefoot
This should be the top ranked comment!

------
wpietri
I was an early adopter (1999-2000), and for years was excited. I was burnt out
on programming and considering quitting the industry, but adopting XP made
things so much saner that it turned things around for me. But circa 2007 I
heard more and more horror stories about companies that were "doing Agile", by
which they meant top-down imposition of some fraction of things, plus managers
slapping shiny new labels on their same old bullshit.

It was heartbreaking to see something that helped me and my teams a great deal
get so throughly misused. It became just another stick to beat developers
with. I spent a lot of time apologizing for all the pain people endured.

It's hardly the first time, though. The original paper on Waterfall basically
said, "This is a thing that is bad and does not work." But people went and did
waterfall anyhow, because a) it conforms to a number of human biases, b) it
reinforces the typical top-down corporate power structure, and c) provides
endless opportunities for people to blame other people for problems. So in
retrospect I'm not shocked at all that we've mostly turned the various Agile
methods into meaningless pablum.

------
bsg75
> People desire a structure that allows them to abdicate responsibility.

s/People/Managers/

In many of the cases I have experienced, agile breaks down into an excuse to
not plan ("Requirements just slow things down!"), and the elements of it that
would drive success are ignored.

So often business leaders just want shit done, and when the technical types
warn about reliability or technical debt, there is a lot handwaving. Thus
short attention spans see agile as a way to justify shortcuts. When this
happens the result can be worse than a poorly executed waterfall model.

Agile works when all the proper elements are used, just like any other
endeavor, and it fails for the same contrary reasons. Developers become
frustrated when yet another path to accomplishment is blocked.

Disclaimer - Am technical manager. Have watched business peers shortcut to
failure. Have fought the battles and lost. Frustration apparent.

~~~
oceanghost
This exactly. Agile allows managers to push all responsibility onto the
developers (design, testing, deployment, ops, customer service, spec writing,
documentation, training, etc), while simultaneously enabling them to demand
milestones every two weeks.

I have seen this taken to the extreme-- the management at one company I worked
for would not specify _ANYTHING_ in writing. Nothing. Not even bullet points
on what a feature would do. They would then micro manage intensely (I had a
non-technical VP doing code reviews on a Senior Architect).

Estimates, however, only included development time, never any other tasks, and
were always challenged. Deadlines were always hard. In short, we had all the
responsibility of Agile but none of the empowerment. Engineering was to blame
for everything.

If you think this was some small crazy startup... This companies revenues are
about 500m a year. Almost every American has our products in their homes.

------
ajarmst
I think some dislike agile because its adherents so often write articles like
this. Pompous, dismissive, assuming facts without providing real measurable
evidence and implying that people who disagree only do so because they're just
not smart enough. If Agile didn't improve your processes, why it must be
because you didn't do it right! And because of that, you hate yourself! You're
just afraid of success! Uh-huh.

------
alkonaut
I dislike it because it makes me a worker at a conveyor belt rather than a
craftsman or artist. The person paying the bill might argue they need
something built so can't pay a craftsman to improvise - which is why this
friction occurs. It's between software development as engineering vs. as an
art/craft. It will always be both.

~~~
wpietri
It depends on which "Agile" you mean, but for me it's just the opposite. It's
no accident that a lot of the people behind the Software Craftsmanship
movement were part of the early Agile movement:

[http://manifesto.softwarecraftsmanship.org/](http://manifesto.softwarecraftsmanship.org/)

------
scarface74
About nine months ago I was hired to create a modern "agile" development shop
with an IT department that had a legacy product built on Access, SSRS, stored
procedures, an old version of Sql Server, etc...

It broke every single rule of what I look for when accepting a job. I only
took the job with the condition that I would have 100% support, budget and
time to set things up right from my future manager.

I laid out my vision....

1\. Realistic timelines based on a 40 hour work week. All estimates and
deadlines were based on realistic hours, realistic staffing levels, and
realistic utilization.

2\. I would be given the time and budget to setup a proper CI/CD platform.

3\. We would put in all of our estimates time for automated testing and code
reviews.

4\. Devs would have direct access to the (internal) customer.

5\. I would have the budget to contract smart people at market rates.

6\. Any dissension from the legacy developers with an attitude of "why do we
need to change. That's the way we've always done things" wouldn't be
tolerated. If they couldn't get on board, I would hire my own team and let the
existing developers support the legacy product.

~~~
fnbr
Did it work? It sounds like you made all of the correct conditions, but that
seems like an incredibly difficult environment for you to succeed in.

~~~
scarface74
It's working well so far. I would never have accepted the job as just another
developer. I only accepted it as an architect that was given the authority to
make the changes. I haven't gotten any push back from the higher ups. I had to
sell everything as a long term cost savings:

\- automated tests keep the cost of hiring QA down. QA only has to test new
functionality. The more automated tests you have -- both unit and integration
tests - the less manual regression testing you have to do.

\- automated testing also allows us to ramp up with contractors and you don't
loose business knowledge when people leave because the business logic is in
the automated tests - not a bunch of documents in SharePoint. If a contractor
comes in and makes a change and the tests break, they've broken a piece of
business logic.

\- Once everything is setup, and documented, you don't need dedicated "release
engineers" all releases are coded with Powershell and configured with Consul.
We treat servers like "cattle not pets".

We also based the project on Mongo and not sql server so we don't have to
worry about database deployments. We decorate the fields in our POCOs that are
being stored with attributes that tell the individual services at startup to
auto create any missing indexes that we need. Schemas are enforced by
microservices that are the only way to access Mongo.

------
martijn_himself
The first realization should be that Agile is not a silver bullet and is not
needed to build great software. Great software was built before Agile existed.

People who care passionately about technology and software build great
software.

On recent Agile projects I have been involved in, a lot of Agile 'artifacts'
were produced (mostly walls covered in Post-it notes). Software seemed to by a
by-product and didn't really feature much.

I think this is a result of the 'busywork' Agile created.

~~~
lj3
This is something I hadn't considered. Thinking back on it, the teams I've
been on that did agile had 3 or 4 times the number of managers that non-agile
teams did. You needed more people to enforce the process, wrangle the
engineers, plan the meetings and make sure that wall of post-it notes was
updated. Something I frequently heard was that programmers were paid too much
to waste their time playing arts and crafts.

------
TimJYoung
When software projects fail, it's natural to think "wow, if only we had
organized things in this way...", or "if only we had a more accurate
schedule...", but it's just a way of ignoring the elephant in the room: your
developers weren't up to the task. Think about it this way: if your developers
knew about all of the issues that would result in a failed project and a)
didn't tell you or b) didn't quit if you ignored their warnings, then what
kind of professional developers are you employing ?

This micro-management of the entire software development process is completely
unnecessary and contrary to every bit of real-world evidence that we have
about what has made certain software projects successful, and others not.
Ambition, drive, and a penchant for excellence is what makes great software,
not a bunch of managers pushing along a group of mediocre developers like
cattle.

~~~
itsdrewmiller
Hardly anyone is going to quit just because you ignore their warnings and let
them work on a project doomed to fail, barring a significant equity stake.
Software projects fail due to bad management, not (solely) bad developers; you
go to war with the army you have.

~~~
TimJYoung
Would _you_ spend a year or more on a project that you knew was going to fail
2-3 months in to the project ? I certainly wouldn't, but maybe I'm in the
minority. It certainly doesn't look that great on one's resume...

~~~
eesmith
Really? I'm sure some would regard it as an example of professionalism, "going
down with the ship", "when the going gets tough ...", etc.

Some people would jump at the change to learn a new technology on the
company's dime, if they know that the project failure can't be attributed to
them. Eg, a front-end engineer could say "we developed an Angular2 front-end
which was on-time and tested well, but the back-end engineers failed to
<insert failure here>."

Do project failures really look that bad?

Kent Beck and Ron Jeffries famously employed worked on the Chrysler
Comprehensive Compensation System, which helped establish Extreme Programming.
[https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...](https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System)

What does it mean then that after the first delivery, the project's customer
representative was burned out and couldn't be replaced, the software was only
ever used for 10,000 of the 87,000 people it was supposed to be used for, but
even with the smaller number it still took 9 hours to run, and new developed
stopped two years later, never reaching the original design goal?

If project failures look bad, how is it that XP ends up with such a good
reputation?

~~~
TimJYoung
Sorry for not replying sooner, I missed your reply.

I should have been more specific about the context: I'm talking about failed
projects that were doomed from the start, and _known_ to be in such a state by
those that were involved. There are many (most ?) projects that look okay
right up until the implementation when all the problems become visible. Those
types of projects are fertile grounds for learning from experience, and I
would categorize them as valuable experiences.

Obviously if a developer is in a junior position in a project that encompasses
a small army of developers, then they may not have any problem with staying on
with such a project. But, I would gather that these types of projects are
pretty rare, and that most projects involve much smaller teams. In such an
environment, the stress and toll on one's family life and health aren't worth
sticking around for, even for any learning experience that one may gather from
the failure. It's a much better situation to simply learn the involved
technologies on one's own in your spare time than subject oneself to that
level of harm.

~~~
eesmith
Yet we know that people join these projects. Yourdon's “Death March" covers
the topic. I haven't read it in a while, but according to
[http://wiki.c2.com/?DeathMarch](http://wiki.c2.com/?DeathMarch) the first
chapter includes "what motivates developers to join them".

Looking around now, [https://www.quora.com/What-is-it-like-to-work-on-a-death-
mar...](https://www.quora.com/What-is-it-like-to-work-on-a-death-march-
software-project?share=1) summarizes what people do in these sorts of
projects: "(a) follow all orders you are given, (b) avoid being given orders
if you can (i.e. don't volunteer for more work), (c) always appear busy and
productive, and (d) start doing side projects (and, possibly, looking for
other jobs) to stay sane. A death march project can be a great time to build
unrelated skills on the clock, because there tends to be a lot of downtime due
to miscommunications. ... keep quiet, always appear busy, and focus on your
own career vector."

This agrees with my understanding, which is why I don't think it's such a CV
death knell as you suggest.

------
smoyer
I'm not sure that developers dislike those they work with so much as they
dislike being managed - the fun part of the job is exploratory programming and
chasing technical curiosities. Having a manager and customers means we
actually have to create something that works and generally includes more
"drudge work".

If developers dislike agile, you'd expect them to be happy with BDUF
(waterfall) and I never hear people saying they're happy with book-sized
specification documents.

Isn't this really the difference between computer science and software
engineering? As developers we have to straddle the fence.

~~~
TimJYoung
Software developers are human beings. This seems like a "duh" moment until you
realize that we routinely ignore this basic fact. As human beings, we operate
best when we feel like we're doing something important or valuable. If we are
tasked with something that is neither, then it is up to the person that is
assigning the task to acknowledge the situation and make it be known that
"taking one for the company" won't go unnoticed. There are also additional
compensation options that could be used to make the whole situation more
tolerable. Something along the lines of "Bill spent two weeks documenting that
entire area of the product that everyone is so wary of altering, so he's
earned that extra 3 days of vacation".

Edit: In case it wasn't clear, I agree with everything you're saying. However,
I do think that good managers that understand their developers can make things
work and keep everyone happy.

------
SAI_Peregrinus
Proper Planning Prevents Piss-Poor Performance.

Agile encourages staying flexible and able to change plans on a whim. In
practice that tends to mean that people using agile processes don't plan long
term. Piss-poor performance is the result. Breaking tasks down into manageable
pieces is hard, and requires good long-term planning for any significant
project.

Agile in practice is "weeks of work can save you hours of planning".

~~~
jalfresi
This my experience too - agile seems to exist because clients and middle
management refused to determine and plan exactly what the want developed,
preferring to "know it when I see it". Agile encourages this attitude.

~~~
scarface74
No one knows what they want until they see it. They may have some vague idea
but without seeing at least a minimum viable product or at least a non
production ready proof of concept how can they know what they want?

The other side of rapid iteration and emergent design is building a system
with change in mind, not over architecting and living by the principle of
YAGNI - You Ain't Gonna Need It.

It's the job of the architect who should have both the people skills and the
technical skills to give the customer what they want and not what they ask
for.

------
makecheck
Processes are needed for sanity, and not much else. Don’t be the baker who’s
really firm on a choice of a 9x13 pan and the entire set of ingredients for a
cake, only to find out that people want cookies.

To move quickly, you really need just two things: a way to make sure things
don’t change unexpectedly, and a way to recreate anything you had before
(where the 2nd is a crutch if the 1st fails). To have _sanity_ , you need
somebody setting a direction (“we’re doing this”), and somebody deciding what
can wait.

For software, this means things like: “for Pete’s sake, use revision control”,
“track versions of dependencies”, “back things up”, “write scripts instead of
step-by-step instructions”, “test somehow”, and “track problems”. There is no
“daily one hour meeting” phase of software development.

------
kps
The difference between agile and Agile is the difference between a democratic
republic and a Democratic Republic.

------
nikanj
Because a lot of places assume the dev team can run an ultra-marathon in an
hour, by dividing it into 500 hundred-meter dashes.

------
adreamingsoul
I love Agile and Scrum for solving my own problems. Nothing is better than
being able to iterate on an idea to determine if it's right or not.

However, I mostly witness selfish, political, or misinformed ideas being
dictated as "requirements". I learned really fast that stakeholders do not
like their ideas being questioned with data points from a scrum research
spike.

So who enjoys wasting time when your professional viewpoint won't be heard?

If management or stakeholders are unwilling to listen to the team that solves
problems for a living, why should I/we waste energy on Agile or Scrum?

------
sgt101
Because it's misused as a way of doing things on the cheap, and the people who
have to live with the consequences are the developers.

The anti-patterns of Agile are...

\- no documentation

\- incoherent design

\- no tooling

This doesn't have to be Agile, but often is.

------
a3n
I dislike it because it forces you to think, work and _report_ almost
exclusively "in the small." I prefer to focus on larger scope, not merely live
surrounded by a fog of scope, while working on the small things that
contribute to the larger scope.

I eat hamburgers, not bites.

~~~
humanrebar
I'm the same way. Though you need the whole team working on the same larger
scope. The Agile approach is to break everything down and make many small
adjustments to make sure that happens.

That's certainly not the _only_ way, however, to ensure a common vision of the
future.

------
throwme_1980
Truth is you need to get s __t done, I see a lot of mediocre developers hiding
behind agile processes, when they can 't figure out something they throw their
hands in the air and scream "bad requirements" , boohoo man-up and do the
business.

------
empath75
I feel like in order for agile (and devops) to work, you have to at least half
invent it yourself, before realizing what it is. If you try to just impose it
on a team, then it get a little cargo cult-y and people don't understand why
they're doing it.

------
thisisit
This like essentially justifying - "Why do X dislike Y?" questions by the
person who loves Y. It is not surprising that there has to be set of process
or steps when doing anything, and I mean anything. The problem arises when Y
is suited for type A projects but just because the Manager has read about Y in
some magazine he thinks "one size fits all". The problem can be seen from the
blog itself. The Toyota Way and contextual changes. In software sometime
defining the context itself becomes impossible. It certainly is more difficult
in a company which has no other defined processes but wants to implement
Agile.

------
sli
In and of itself, I don't see much wrong with it. Agile itself does not seem
to be the problem.

Problems arise when it is heavily abused and applied incorrectly by
management, in my experience. My first time doing Agile (well, SCRUMM, but
bear with me here) was someone using it to manage multiple unrelated projects
at once. Predictably, it crashed a burned miserably. The person who decided on
it was suckered by the buzzwords but failed to actually understand the purpose
of the process.

My current company uses SCRUMM quite effectively, and it's been a wildly
different experience. It probably helps immensely that the people in charge
are also developers.

------
PaulHoule
I think those conflicts exist in all so-called "teams", but in Agile those
conflicts become sublimated by a grumbling about "process" on a sprintly, if
not daily, basis.

If your plan, on the other hand, is to have three people develop three
separate parts for a year, and then think you are going to stick them together
and release in two weeks, people can avoid interpersonal conflicts entirely
for a year, after which there is a crisis, which is often survivable by the
participants because there are already so many chips in the pot...

~~~
convolvatron
there is a pretty vast middle ground between 'talking every day for a year,
and never making any plans' and 'make a plan for a year, don't meet in the
interim and try to integrate then'

make plans. try to gauge costs. change plans when necessary. integrate as soon
as is reasonable. use consensus to drive structure/interfaces. maintain a
testable artifact.

maybe running a service is different, but variants on the above seem to be the
only thing that works for software.

------
WheelsAtLarge
Simple, developers dislike it because it leads to very messy code, quick fixes
that lead to messier code, and a stressful work environment. On the other
hand, waterfall leads to missed deadlines, cost overruns and applications that
don't meet needs.

I think we need something in the middle. Does anyone have any ideas?

I suspect the fix will be on the type of software app that people are writing
rather than the way apps are written. Monolithic apps are hard to write and
maintain so we need to think small and generalize software something similar
to lego bricks.

------
hibbelig
Maybe in some companies they do Half Arsed Agile, instead of Agile?

[http://www.halfarsedagilemanifesto.org](http://www.halfarsedagilemanifesto.org)

SCNR, it's too beautiful...

------
jeffdavis
Because it doesn't really mean anything, and people act like it does.

Maybe there's some description somewhere with meaning, but it doesn't matter
because the meaninglessness has prevailed.

------
strictnein
Jira

The Greenhopper plugin was a joy to use, 10 years ago.

Jira Agile is an atrocity, especially in an enterprise environment. About 5%
of the time you'll actually be using it to help you do your job. You'll spend
far more time answering questions and doing risk analysis, etc, etc all at the
request of some random person you've never met who needs reporting on some
random bit of information that is of no consequence.

It's used as a reporting and tracking tool now, not a tool to handle
development flow.

------
wolfi1
scrum could work, but only in speciql cases. for example, it cannot deal with
new coworkers, at least not in the teams I experienced. it could work for ad
hoc teams with the same knowledge, but in practice that is never the case

------
true_tuna
Standups

------
transverse
Personally I blame Scrum or attempts at Scrum rather than Agile. Kanban is
more flexible.

Effective Scrum just means sacrificing code quality sufficiently to make your
ticket fit your sprint. /s

------
kapauldo
Unrealistic expectations.

------
flaviusas
No sane developer dislikes agile. We only dislike agile-done-wrong.

