
Coconut Headphones: Why Agile Has Failed (2014) - numo16
http://mikehadlow.blogspot.com/2014/03/coconut-headphones-why-agile-has-failed.html
======
sageabilly
The best example of this I have seen lately:

Big Software Company officially changed over to Agile this year. Now has two-
week development sprints. Any customer who calls in with huge, flaming, earth-
shattering issues with the software is now told that the earliest their issue
can be brought up is whenever the current sprint is over. There's absolutely
no leeway whatsoever to do any ad-hoc development for customers (frequently
Fortune 500 or 100 who are paying millions for their software support.)

~~~
mindcrime
_Big Software Company officially changed over to Agile this year._

If they phrased it that way, they probably didn't. There is no such thing as
"Agile". That is, "Agile" is _not_ a methodology that you can adopt. It simply
does not exist. There are a number of processes out there (Scrum, XP, Crystal,
etc.) that can be _described_ as "agile" because they conform to the tenets of
the Agile Manifesto to varying degrees. But anytime you hear a company say "we
adopted Agile" you already know that they don't know WTF they are talking
about, and can stop listening right there.

Sadly, misunderstandings of "agile" are so pervasive that the term basically
has no meaning anymore. Most - if not all - of what the author of TFA is
ranting against, is very explicitly _not_ "agile" in any sense.

I wouldn't say "agile" (that is, "a set of principles and ideas as articulated
in the Agile Manifesto) has failed at all. I'd say a lot of people who don't
understand what "agile" means have overloaded the term with another meaning,
which is being the word to describe their fucked-up hybrid of waterfall and
cowboy coding.

~~~
dragonwriter
> If they phrased it that way, they probably didn't.

A central point of TFA -- which the grandparent post offers an example of --
is that "Agile" has "failed" because rather than adopting the values of the
Agile Manifesto, organizations adopted cargo-cult "Agile" rituals without
understanding the principles and purposes of Agile (TFA goes on to claim the
"core" point is that non-technical managers of technical projects will always
fail, but while I think the cargo cult observation is valid, I think this
conclusion is a leap that is unjustified from that observation -- the
principles of the Agile Manifesto are non-technical principles and agility and
adaptability aren't things that take particular domain-specific skills to
understand. Strong top-down directive management that isn't respecting and
leveraging subordinates expertise within their respective domains in terms of
choices of _how_ to achieve goals -- including technical experts on projects
which have a technical component, which may or may not be purely or even
principally technical projects -- is going to fail, but that doesn't mean that
managers need to be technical if the project is technical, or even that a
binary technical/non-technical distinction is appropriate for projects.)

~~~
mindcrime
_A central point of TFA -- which the grandparent post offers an example of --
is that "Agile" has "failed" because rather than adopting the values of the
Agile Manifesto, organizations adopted cargo-cult "Agile" rituals without
understanding the principles and purposes of Agile_

Right, and I agree 110% with that. I'm just not sure I'd agree that that means
"agile has failed". There are companies out there using agile oriented
processes and having quite a lot of success with them. When done well, Scrum
really is a very effective process. I remember when I worked for Lulu.com, we
had a great scrum-master, a company culture where everybody, _including the
business people_ , "bought in" to the approach, and a group of really talented
developers, and it all worked great for us. So had "agile failed" there? I'd
say not.

What I will definitely agree with, and what I've said myself, is that the term
"agile" has been overloaded to the point of being essentially meaningless now,
except in a very constrained context.

~~~
amyjess
> I'm just not sure I'd agree that that means "agile has failed".

I think that's because you're disagreeing with _what_ Agile has failed _at_.
You're interpreting it as "Agile has failed to be an effective process", while
GP and the article are interpreting it as "Agile has failed to achieve
widespread adoption".

Agile can certainly be an effective process, but that doesn't matter if 90% of
the companies that claim they use Agile are actually using something very un-
Agile that they happen to call Agile. This actually _raises_ the barrier to
Agile being adopted by more companies, because now everyone hears "Agile" and
automatically thinks of it as this... thing that's adopted by MBAs instead of
what it actually is, so they reject it.

~~~
derefr
I think there's a third interpretation: "Agile has failed to spread the spirit
of its message to its followers without being corrupted in the process."

'Agile' has achieved widespread adoption. Agile techniques have not. Thus, if
'Agile' were a person—the founder and namesake of a religion, say—they would
be ashamed at what their followers were doing in their name.

~~~
mindcrime
Fair enough. I think we're basically in agreement.

------
nine_k
In short: _«The core problem is that non-technical managers of software
projects will always fail, or at best be counter productive, whatever the
methodology. Developing software is a deeply technical endeavour.»_ Technical
excellence or at least competence is key and can't be replaced with any
process. Estimates are not very useful; technical debt is dangerous toxic
waste, and any process that does not treat it well is bound to fail.

A discussion 2 years ago:
[https://news.ycombinator.com/item?id=7389940](https://news.ycombinator.com/item?id=7389940)

~~~
capkutay
If that's the core message, why is the article titled 'Why Agile has failed'.
Non-technical managers would ruin any engineering project whether it's agile
or waterfall.

~~~
hga
Because "Agile" (or at least some forms of it) claim to have solved this
problem? Something I'm not aware of any other methodology (family) doing.

------
hipsterrific
This article hurts. I'm currently contracting with a large company and they
said they were agile. The only agile thing about them is their cultic
insistence on two week sprints and retros, other than that, the project rots
from within. Case in point: team I work in takes care of all the web front
end. One team needed some web work but then management came thundering down to
us demanding that we finish another module because someone opened their mouth
and over delivered, now it's time to save someone's hide.

Imagine having one team yell at you while management yells at you. Oh, and did
I mention that management wanted 100% feature complete on a module that was
30% done? Genius.

After reading this, my liver was like "oh sh __that hurts. "

~~~
dctoedt
> _demanding that we finish another module because someone opened their mouth
> and over delivered, now it 's time to save someone's hide._

Question: Did you mean over-promised (vice over-delivered)? If the latter,
could you please explain what you meant? Sorry if I'm missing the obvious; I'm
not a dev.

------
noobiemcfoob
"Hard deadlines, especially micro-deadlines will result in poor quality
software that will take longer to deliver."

^ This. This. This. I can't say this enough. I understand business is
business, but that side of a company needs to be more flexible for
development. Hard deadlines only lead to cutting corners and poor, quick
design decisions that make everything there after much worse.

~~~
mindcrime
_Hard deadlines, especially micro-deadlines will result in poor quality
software that will take longer to deliver._

I used to think this way. But the longer I've been doing this, the more I
realize that _some_ (but definitely not all) hard deadlines exist for good
reasons. There are external realities that a business has to deal with, like
tax laws and accounting guidelines, that change, and go into effect on set
dates. And there are times when you have a very specific reason for wanting at
least a demo of $NEW_FEATURE before, say, a major marketing event like a
trade-show or conference. These things aren't arbitrary and made up just to
piss off the developers, even when it seems that way.

However... and here's the part that nearly everybody seems to miss: If you're
using a good agile based process (say, Scrum, done well) "hard deadlines" are
a little bit less of an issue, exactly because you're always working on "the
most important thing you could possibly be working on" at any given time, and
at the end of a given iteration (when you _do_ ship functioning code), you at
least have "the most complete possible version" available, even if it's not
100% complete. This is why prioritizing requirements is so crucial, but sadly,
a lot of the business users who nominally should be doing the prioritizing,
don't understand how this concept works.

~~~
TheCoelacanth
Yes, bad things aren't always possible to avoid. That's just the nature of
human existence. But you shouldn't go out of your way to create problems for
yourself.

Some deadlines are unavoidable, but you shouldn't create artificial deadlines
and you definitely shouldn't create an artificial deadline for every single
micro-task that someone is working on.

~~~
mindcrime
_Some deadlines are unavoidable, but you shouldn 't create artificial
deadlines and you definitely shouldn't create an artificial deadline for every
single micro-task that someone is working on._

Totally. I agree with that 100%.

------
arenaninja
This is the area of software development I actively dislike. I've had
interview questions about whether at work we practiced agile, or SCRUM or some
other crap. I'd much rather work than relegate time to learning about the
trendiest way to ship.

When I was in charge of development, it was simple. Ship as soon as it's ready
as long as it's not a Friday, bugfixes go all the way to the top of the pile.
I don't even know what scrum means. If it's dead, I'm glad I've heard the last
of it.

~~~
Cymen
What size teams have you worked on? What has the experience level been across
the team (was it all experienced, a variety of senior/mid/junior)? My
experience is it starts to get more important when the team gets bigger than
say 6-7.

------
ssewell
Agile methodologies can work, but it often requires a feature-centric
deployment model, not deadline-centric. Having a fixed N-week deployment cycle
can't simply be applied to all products and expect it to work.

I've found that an "Agile" approach can work quite well as long as you apply a
healthy does of common sense to it.

I think to often people forget that product management frameworks are there to
create a common language and set exceptions, not blindly dictate exactly how
one should operate.

------
PythonicAlpha
My experience with agile development in companies: It is largely used to
delegate the responsibility for a project and the results away from the
management to the developers.

They just throw the objectives (made by the management) over the wall to the
developers, those have to give an estimation and the managements is free of
any further responsibility.

So the developers will in practice exploit themselves. This already was
profitable in the automotive industry, where instead of the management, the
fellow workers pressured the coworkers. The peer-pressure can be even more
pressing than any management mechanics.

This finally of course is the opposite of agile development as it meant to be
-- but that is nothing, that anybody in management would care about. The label
"agile" is good enough and even most employees don't see how they where
betrayed. They think (at least for some time), they where "empowered", but the
real empowerment is, that they are now free to enslave themselves for the
boss.

------
andyidsinga
Although I agree that putting non-technical managers in charge of a technical
team can be a problem in some cases - I think the article focuses a little too
much on that aspect vs what I think may be more problematic -- that, in my
experience, focus falls on process dogma (even agile's) when there isn't
enough interaction with the user.

From the start of the article:

> They identified that the programmer is the central actor in the creation of
> software, and that the best software grows and evolves organically in
> contact with its users.

I find myself echoing this a lot lately - that contact with users is the key
to success in software development.

Note that this has to be told to both management _AND_ engineers. I've met
lots of engineers in my time that don't want contact with users ...that is a
problem.

~~~
mindcrime
_Note that this has to be told to both management AND engineers. I 've met
lots of engineers in my time that don't want contact with users ...that is a
problem._

That's a fair point, and it also comes out when you see hackers denigrate the
role of "product manager". I mean, yeah, I get it... there are bad product
managers who are completely non-technical, and clueless. You don't have to
tell me. BUT... a _real_ product manager is technical enough to have an
intelligent conversation with the developers AND enjoys talking to customers
and can "dumb things down" enough to talk to non-technical people and serves
as that "bridge" between the users and the developers (go ahead, insert
"Office Space" reference here).

The problem is, people who actually have the required combinations of talents
to be good product managers are very rare, meaning that most product managers
suck. But when done right, it is a valuable role.

~~~
andyidsinga
totally agree that a real project manager will be technical to some degree --
even if just an aficionado / technologist type.

I do like to balance the scales a little and defend less technical leaders --
I've had a few really good non-technical leaders/bosses in the past 20 years.
They were so good because they a) respected and trusted their technical teams
immensely and b) made a really hard effort to learn from them such they could
do the bridging you describe.

------
Tekker
I think the overarching aspect of agile has failed, in part because it
requires more implementation than most companies are willing to put up with.

I see, in general (and I am a certified scrummaster, FWIW), that companies
tend to embrace sprints - usually going for two weeks - and daily standups
(which they might do poorly, but at least they try). Everything else -
estimation sessions, lessons learned, burndown charts - are up for grabs.
Maybe that's a failure of the company. Maybe that's a failure or Agile, for
failing to take into account the normal inertia of companies - I don't konw.
It is better than waterfall, but it's not fully embraced.

------
Florin_Andrei
> _The original agile manifesto was very much about self organizing teams, it
> would be great if we could get back to that._

Sorry, not going to catch on. Corporations make money. Where there's money,
there are power struggles. Where there are power struggles, nobody is going to
relinquish power and let people "self-organize". Sure, there might be
exceptions, but the vast masses out there will never follow.

~~~
hga
The trick here would be convincing the right people that letting "us" have
more power and self-organize would provide them with more money and power.

In my experience, a lot of it comes down to the issue of control (which I'll
admit I'm predisposed to see). I've seen more than a few people who'd rather
have their projects fail, lose their jobs, or even kill their company than
lose their perception of control over "us".

------
grandalf
I've found that organizations who strongly embrace agile or other management
fads/tenets are often recovering from one or more projects that took too long
or went over budget... someone got blamed, someone hired a consultant or read
an agile book, and the next thing you know the rules of agile are used as
weapons in whatever internal political battles predated the change.

Or, non-technical management is being criticized for too-slow development and
an exasperated engineering/product team resorts to agile as a method of
radical transparency (you were on board with the sprint plan, we delivered, so
stfu, etc.)

I'd say any of these are pretty big warning signs about an organization's
culture... in particular they likely reveal that the culture doesn't
appreciate good engineering practice or good product practice.

------
zorked
Good,a while ago it was the contrarian, underground cult, then it was all the
rage, then you were not a professional if you didn't worship it, then the
cracks started to show, now it's failed and passé.

When should we expect the revival?

~~~
maxxxxx
Like all other trends it has a lot of good aspects to it and will come back in
some form.

Right now functional programming is the rage. Just wait until some functional
programming projects fail. Then people will say "functional programming has
failed". Happened with object oriented programming.

There is no methodology that can be subverted by people who don't understand
it.

------
ThrustVectoring
This is exactly why John Boyd never wrote any books explaining his thought
process - his entire point is to drop fixed and inflexible doctrine in favor
of striking at the heart of what makes military operations work, and
explicitly serializing your mental models is a quick way to convince people to
interpret them as a fixed doctrine.

~~~
hga
Example of "cult doctrine" he would be very aware of: in Vietnam, the Air
Force was using WWII fighter formations, which granted them 1/4th the power
the Navy's modern, jet adapted ones had.

In part, this wasn't seen as a problem by the flight leaders, who would tended
to be senior officers, since they got all the action while the other 3 had to
mostly concentrate on staying in formation....

------
JustSomeNobody
The problem is that management has to do "something". When the developers are
off designing and coding, what are the managers supposed to do? They have no
clue, so they adopt "agile" so that they can appear to be busy collecting data
on how well the team is doing.

