
The Failure of Agile - ingve
http://blog.toolshed.com/2015/05/the-failure-of-agile.html
======
lkrubner
The only "process" that I've ever seen work is "have someone really good in
charge." It doesn't matter if they are male or female, and I've learned that
it doesn't matter if they initially have a technical background.

The best project manager I ever worked with, in the 16 years I've done this
work, was a woman who initially did not have a technical background, but she
was willing to dive into the technical end of things. She eventually taught
herself SQL and how to write Cucumber tests, so she could better QA test the
code she was overseeing. I met when she was in her 4th year, and she had an
impressive skill for estimating how long a given task would take, and whether
things were going well or badly.

If you have someone really good in charge, and they call their system "Agile",
then it might appear that Agile works. If you have someone terrible in charge,
and they call their system "Agile", then it might appear that Agile sucks.
Likewise, if they call their system "XP" or "Deep Review" or anything else.
But the only process that seems to matter is "have someone really good in
charge."

~~~
joe_the_user
Uh,

I can't see how a person can have "goodness" without that goodness having a
structure which could be studied, systematized and taught somehow.

Whether that could be made into the kind of system marketed by gurus is
naturally a different question and I'd be skeptical about that.

~~~
maratd
> I can't see how a person can have "goodness" without that goodness having a
> structure which could be studied, systematized and taught somehow.

How do you teach someone an attention to detail, good work ethic, and
perseverance?

Those are character traits, not methodologies. If a PM has those 3, he'll be a
good PM regardless of anything else. Actually, if someone has those 3, they'll
be a good _anything_.

Agile or something else might make someone _better_ , but they can't determine
if someone is _good_.

~~~
vlasev
You can teach them. I personally had a lot less attention to detail before
studying math. Good work ethic and perseverance can be taught as part of
reaching a bigger goal, for example in sports.

~~~
bananaboy
Yeah I agree, but I suppose the person has to be willing to learn too. I can
point to a couple of specific teachers and lecturers during my school years,
and then the technical director at one job, who all influenced me a lot and
shaped my work ethic and desire for attention to detail. Colleagues and
friends may not have felt as influenced by the same people.

~~~
vlasev
It takes two people. I guess I'm implicitly assuming that the student will be
relatively bright and wiling to learn but will be lacking some of those soft
skills at first.

------
lawl
I've unfortunately never seen Agile work. I had one project where we basically
had our own process that just kind of evolved, a mix between waterfall and
agile I guess. That actually worked well for a year, until management had to
fix it, because we weren't Agile. We actually went from 2hrs of meetings/week
to _almost two full days, I 'm not shitting you_ (to be fair, they went a bit
back on that and cut it down to one day fairly quickly, but we still wasted
more time by becoming more Agile).

Then my job was to fix others peoples projects from companies that weren't
familiar with the technology they used as a consultant. All of them were
agile, SCRUM and SCRUM of SCRUM.

And it just didn't work, Ive never seen such dysfunctional teams before.
Nothing worked. I realize I've probably only seen the bad side of SCRUM
because whenever I got called in they were behind schedule and already fucked
up the project anyways.

I think SCRUM can work, maybe, hopefully. But to this day I have yet to see it
happen. You have to do it right, and even with basically zero experience with
SCRUM I was able to tell that they weren't doing it right, they were just
wasting time and not having ANY coordination whatsoever.

I think what others have said here is right, if you have a great team, it will
organize itself anyway. If you have a bad team, jumping on the agile bandwagon
won't help you.

~~~
lojack
> we basically had our own process that just kind of evolved, a mix between
> waterfall and agile I guess.

Interestingly enough, I find that to be something more in line with agile than
the way most teams treat agile process. The agile manifesto itself event says:

> Individuals and interactions over __Processes __and tools

Which in a way makes most agile processes a sort of oxymoron. At the end of
the day we just need to understand that we're building software, and we need
to do more of what helps us build software and less of what prevents us from
building software. Agile (or what people call agile) can do both.

~~~
lawl
This.

Basically, our process before was that the PM would plan a release with the
customer and a few senior devs, distribute the tickets needed for that release
to team members, and then the team shifted them around between eachother
trying to make it work, sometimes we couldn't fit some tickets in, sometimes
we were able to fit a bit more in. These were fairly long cycles like up to 3
months or even longer in one rare case.

Then we became Agile. When you have 20 devs on a project, your standups won't
take 5 minutes. Estimating the tickets won't be done in an hour because too
many dependencies. They tried to split teams up into two, but then team A had
no idea what team B was doing and there was just way more overhead.

Most people will look at you in a weird way when you tell them you had 20 devs
in _one_ team. But what can I say, it certainly worked better than the other
things we tried.

As I said, I'm sure it _can_ work, but you need to do it right, and we
certainly didn't.

------
mpdehaan2
Most of the agile problems I've seen have been organizations cargo-culting
things they've read, rather than trying to actually be dexterous. Big-A agile
versus, well, "agile".

Scrum has been the largest offender - squashing discussion in standups,
allowing scrum to erode QA process, rote meetings that take 50% of the week,
story points and refusing to discuss timetables in hours when absolutely
needed, reporting status multiple times, having others estimate tasks who are
not doing those tasks, etc.

These organizations that have done so have been some of the least agile, and
waterfall-esque organizations can even be better. (They planned up front well,
they changed a few minor things in the middle maybe, but cut out the
overhead).

~~~
warfangle
I think most teams that implement/try to implement agile/scrum/xp and end up
disliking it / failing at it completely miss the point of the retrospective
step - and thus, skip that step.

Without the retrospective, it's just modified waterfall.

~~~
mpdehaan2
We had them in about half of the scrum shops. The retrospective, in my
experience, was yet another meeting where things didn't get done either. "We
are having too many meetings" was usually not popular either. Don't get me
wrong, I like _good_ meetings that result in actionable decisions.

My personal view on scrum is it attempts to trick a software team into micro-
managing itself, and it usually results in feeling like kindergarten as a
result.

The better shops have been "agile", but not "Agile", and just did what worked,
and made changes when they needed to.

I don't think a retrospective is essentially required, but the ability to
change and throw out things that don't work -- and have only the right amount
of meetings and to talk about the things that matter rather than a template -
is.

When a retrospective is to make the team feel they have a voice to make
changes, and in reality, nothing changes, that makes the retrospective itself
rather soul-crushing theatre, so everybody just says nice things and hopefully
nobody gets thrown under the bus when "what could have gone better" is
discussed - but often, that still happens.

Scrum is, to me, something people pick when managers don't want to manage.

I like release-early release-often, MVP (in small doses), see
[http://michaeldehaan.net/post/118860078737/the-rock-paper-
sc...](http://michaeldehaan.net/post/118860078737/the-rock-paper-scissors-of-
product-management), and many of those concepts. But I also don't like the
idea that requirements constantly shift - which means architecture can't plan
ahead.

I also find Scrum usually is so time-pressured, it can create a constant
death-march, and also tends to sacrifice time to crush technical problems as a
result - there's no "getting done early, so time to fix the architecture over
here", etc. If you have a PM that doesn't allow time for such things, it can
be rough.

(Not everything fits in two week blocks either)

~~~
wavefunction
>>I also find Scrum usually is so time-pressured, it can create a constant
death-march, and also tends to sacrifice time to crush technical problems as a
result - there's no "getting done early, so time to fix the architecture over
here", etc.

Sounds like your teams were underestimating task effort.

>>If you have a PM that doesn't allow time for such things, it can be rough.

Anything's rough with a shitty PM, which is what you've described.

~~~
zelos
I think one problem is that Agile gives a numerical value to how much work has
been done: story points.

Management get addicted to getting more story points, and any push back from
developers that would lower the number in the short term is ignored.
Seriously, I've seen "average story points per developer per sprint" reported
to 2 decimal places as if it's a meaningful number.

~~~
warfangle
That's a problem with management. All of the agile/scrum resources I've read
exclaim, in big bold letters, 'THESE ARE NOT METRICS TO EVALUATE PERFORMANCE;
THEY ARE FOR ESTIMATION OF EFFORT'

~~~
emodendroket
Head shops have big signs stating that the goods for sale there are strictly
for smoking tobacco too.

------
jfabre
Every time I read one of those posts, it makes me go back to
[http://programming-motherfucker.com](http://programming-motherfucker.com) and
I enjoy it just a bit more than the previous time.

~~~
tim333
That's rather good.

~~~
geophile
It is, but I can't look at that website for more than 30 seconds without my
eyes burning out.

------
commentnull
The article starts with the current note - agile as it was preached was never
actually achieved, and most companies and practioners are doing it "wrong"
(for varying degrees of wrong).

But then it goes downhill with proposing yet another model that will people
will try to adopt verbatim, and again, experience failure to implement.

Software is hard, people are hard, so the idea should be to have as little
process as possible. Most of it exists as arse-covering material anyway.

What really killed agile fwiw, where the consultants, going from development
team to team, peddling false hope, snake oil, and tedious time zapping process
that people learnt to game rather than actually deliver.

Of course, someone will pop up saying agile is awesome, they love the daily
scrums, the project is fab, the sky is blue, etc. Question is: can it be
better?

~~~
city41
In my experience, the people who say agile is awesome would likely say any
process is awesome. Because the true awesomeness they are experiencing comes
from being on a good team. After wading through years and years of agile, even
working for a major agile tool maker for a while, I've come to the conclusion
what process you choose isn't that important. Get a good, passionate, driven
team together, and they'll figure out how to kick ass. Without that
ingredient, nothing else matters.

~~~
dragonwriter
> In my experience, the people who say agile is awesome would likely say any
> process is awesome. In my experience, the people who say agile is awesome
> would likely say any process is awesome.

Agile is awesome because its not a process, but a set of principles which
addresses exactly the problem that context-blind adoption of processes creates
that makes good teams mediocre and bad teams worse.

Most of the processes sold in a context-blind manner as "Agile" suck, but they
are a recreation of exactly what the Agile Manifesto was a reaction against.

~~~
city41
That's true in theory but rarely in reality. The reality is Agile is a
process, often a rigid one. I find good teams resist bad process, and mold
process to their needs. For teams that do that, whether they are "agile" or
not largely becomes irrelevant. I will admit I have found through lots of
experience that the "agile movement" is silly at best, so I'm perhaps a bit
biased.

~~~
dragonwriter
> The reality is Agile is a process, often a rigid one.

No, the reality is that Agile is not a process, though there are a number of
_different_ processes sold as "Agile". (The most common now seems to be Scrum
as defined in the Scrum guide and a number of variants on it; for a while XP
was somewhat prominent as well.)

> find good teams resist bad process, and mold process to their needs. For
> teams that do that, whether they are "agile" or not largely becomes
> irrelevant.

Teams that do that _are_ Agile: that's exactly and all of what the Agile
Manifesto says.

> I will admit I have found through lots of experience that the "agile
> movement" is silly at best, so I'm perhaps a bit biased.

The thing is the "Agile movement" consists of two separate and opposed forces:
one (and the origin of "Agile") is people promoting exactly the behavior you
mention characterizes good teams, the second (and the thing you seem to have a
problem with) is people using the name that the first group came up with to
promote exactly what the first group is reacting against -- rigid, context-
blind adoption of externally-developed process (largely as a reaction against
the threat posed by the good ideas of the first to the second groups pre-
existing business of selling rigid, context-blind processes.)

~~~
city41
But the reality is almost everyone who "does agile" has rigidly adopted scrum,
xp, kanban, etc. That is the reality most of us face. Just because a group got
together 14 years ago and created a hypothetical scenario that essentially no
one follows doesn't seem all that relevant to me.

And at the same time, the fact that a good, adaptive team that figures out
what works for them is what you and the original group deem to be "agile"
simply reinforces that the whole thing is ridiculous to me. Why did we need a
name and a manifesto for that?

The end reality is we have an entire industry built around that stupid
manifesto. Sure, it's not what they wanted, but it's what we all got. We would
have been better off without it.

~~~
dragonwriter
> And at the same time, the fact that a good, adaptive team that figures out
> what works for them is what you and the original group deem to be "agile"
> simply reinforces that the whole thing is ridiculous to me. Why did we need
> a name and a manifesto for that?

Because while there are lots of people who won't understand that _with_ an
explanation, and some people who get it intuitively and _don 't_ need an
explanation even with all the noise from people selling one true way, there's
also lots of people in the middle who benefit from people selling there one-
size fits all approaches _not_ being the only voice in the marketplace of
ideas.

> The end reality is we have an entire industry built around that stupid
> manifesto

No, we have an industry that existed _long_ before the manifesto built around
selling canned, context-blind process and jumping on anything even mildly
popular to sell it that, predictably, when the manifesto calling for exactly
the opposite of what that industry sold became popular, jumped on that to sell
_exactly_ the same thing they'd always been selling.

> We would have been better off without it.

No, I think that there are lots of people who have learned something from the
Agile Manifesto, writings actually addressing how to implement its principles
that don't amount to context-blind process, and related movements (Lean
software development, etc.) and applied the ideas to improve teams and make
software in a better way.

Most developers -- before and after the manifesto -- work in places where
management is operated with shallow knowledge and poor respect for their staff
and buying whatever consultants are selling in terms of process, sure, but
that's not the fault of the Agile Manifesto

~~~
city41
You do make some good points. Perhaps my frustration at the Agile Manifesto is
misplaced. I'd still argue that the canned processes that emerged due to the
creation of the Agile manifesto are amongst the worst ones available, but for
sure I have no real proof for that other than my own personal experience.

------
matthewmacleod
I still remain totally unconvinced that 'Agile' is broken, or has failed. I
have worked in places that do FakeAgile, and places that do GoodAgile, and
there are two conclusions:

1\. Bad companies and practices will not be magically fixed by applying
'Agile' or whatever other methodology you want. 2\. When companies do agile
development well, it is effective at solving some of the worst problems that
software development faces.

Apparently I'm in the minority for thinking that Scrum in particular is a
pretty effective development methodology. I'll tell you what our process is.

\- Spend a couple of hours planning a sprint of work. Two weeks, in our case.
During that planning meeting, look at the backlog of features and tickets that
the product manager has built up. Identify tasks we can reasonably accomplish
in that time frame, ensure we have enough information to start, and discuss
each one so we have a clear idea of what it involves.

\- Make sure that those tasks are customer-visible features wherever possible.
It's not always the case that this can be done, but it helps to provide
feedback.

\- 10-minute daily stand-up to discuss any issues and communicate who's
working on what. Also time for the product manager to feed back any
information from outside the team.

\- Work on some tickets. Review the code. Pass them through QA. Deploy them.
Let the product owner receive feedback from customers.

\- Review the sprint when it's done – take an hour, discuss what went well,
what didn't go well, and anything we can improve.

That's the core of Scrum, and I don't see what's wrong with it. The problem
arises when it's abused; story points as burndown charts, or productivity
monitored in terms of 'number of tickets finished', or whole-company stand-
ups, or whatever.

Agile development works well if you're agile. It's not a set of rules that
_must be followed_ – it's a set of guidelines that can help to improve the
development process. If you are performing useless, time-consuming overhead
tasks, then you are not doing Agile – end of story.

~~~
eropple
_> That's the core of Scrum, and I don't see what's wrong with it._

Where does professional development come in, my true Scotsman?

~~~
giaour
From what I've seen, professional development in a scrum shop means moving
from junior developer to people manager.

If you want to keep coding, you're expected to leave within two years.

~~~
eropple
Agreed (though maybe not "two years"), and that was what I was getting at.
Scrum is not a system for investing in people--and _we need to do that_. It's
a fairly exploitative mode of organization and this industry's largely
uncritical adoption of it is something we don't look at particularly often or
with much real gusto.

~~~
matthewmacleod
_Scrum is not a system for investing in people_

You're right – Scrum is a process framework for developing software.

That is _totally, absolutely, 100%_ orthogonal to professional development. I
work in a mostly-Scrum environment as I described; that doesn't preclude
research, or conference attendance, or any other form of professional
development.

Bad culture is bad culture, regardless of development methodology.

~~~
giaour
What you're essentially telling your engineers is that A) doing their job has
nothing to do with getting better at their job, and B) if they want to advance
beyond the junior engineer level, they will have to do so on their own time.
I've seen this referred to as "terminal juniority."

Having a development process that does not produce senior engineers is a
problem, even if you try to make up for it by providing a conference
attendance budget and a Safari books membership. At the very least, such a
process unfairly penalizes those with large personal time commitments.

~~~
eropple
Fantastic post, and I agree. I've always been in a weird place professionally
because I came out of school at a somewhat-above-junior level and so I've been
in an interesting position to watch companies try to mold developers. There's
that "five years of experience"/"one year of experience, five times" thing
people sometimes refer to, and Scrum seems tailored to doing the latter.

Terminal juniority is an amazing term for that. Thanks.

~~~
giaour
Thanks, though I can't take credit for it. I stole it from an epic anti-agile
jeremiad on Quora: [http://www.quora.com/Why-do-some-developers-at-strong-
compan...](http://www.quora.com/Why-do-some-developers-at-strong-companies-
like-Google-consider-Agile-development-to-be-nonsense/answer/Michael-O-Church)

~~~
eropple
Ha, it sounded familiar. I don't always agree with Michael but he's a great
dude.

------
grandalf
Just a quick rant about SCRUM:

I have found that SCRUM is used to allow everyone in the company to believe
that the development team is at maximum productivity. It encourages
conservative estimation, low-ambition projects, and generally business-
friendly, highly measurable pace (with metrics that don't really matter but
sound good).

If you have to resort to SCRUM, your company is probably already toxic (or
else the last company your VP of Engineering worked at was toxic).

When you don't have good product/market fit, everything the development team
builds looks like a miss (because it is) even if the technology works very
well. Thus, good product management is crucial.

In the greater scheme of things it matters very little if every single
features ships two months late. The most important thing is that the product
gets closer and closer to the product/market fit bullseye.

SCRUM insulates developers from managers who would constantly change their
mind and thrash the team around willy nilly, but it also insulates developers
from the realities of the business.

With good product management, everyone buys into the challenge of product
market fit, and everyone wants to apply the right blend of qualitative and
quantitative approaches to build the right thing at the right time. SCRUM is
fine if everyone is already cynical and there is widespread mistrust, but if
you want real team cohesion it's a bad idea.

~~~
fat0wl
I'd like to at least offer some support to this -- I'm not sure I agree with
all of your conclusions but since switching to Scrum mentality I definitely
notice that the goals of our team have become much less ambitious... Rather
than insulating for development cycles that may not yield much for a few of
months but in the end equals proper enterprise architecture, the business/devs
have found it much easier to focus on small iterative tasks that are much more
superficial in the grand scheme of things.

I think engineering processes benefit when they are insulated from direct
scrutiny of timelines. Resorting to tackling smaller, neater issues in Agile
seems to be a sign that there is a lack of technical leadership/vision. This
is not necessarily the fault of Agile (I don't mind Agile, I think projects
can succeed with it if approached properly), I simply agree that increasing
process rigor seems to be a symptom of an engineering/mgmt team that is
floundering.

In short, if your team's problem is that things are getting "messy" and
"hectic" because of too much crappy copy/paste code, I have seen how Agile can
just deepen that wound while masking it in a veil of "tangible progress" seen
in burndown charts. Then, again, if you don't have the right people you don't
have the right people. What else can you say?

~~~
joshdotsmith
I'm guessing if you're the kind of manager that sees progress in burndown
charts you're already on the wrong course as it is.

------
tablet
Almost every new idea in software development is having problems when facing
"majority adoption" phase. Agile definitely is replacing waterfall now and
there are so many people that capitalize on this trend and don't give a shit
about agile roots and principles. Every new wave is eventually hiped and
monetized. Agile is not an exception. It doesn't mean agile is bad, it just
means agile went mainstream with all side effects.

I personally have a strong feeling that this article is just another attempt
to monetize agile, by selling "agile failure". Agile is not failed for sure.
Some people did.

~~~
marcosdumay
Every new idea in management have problems at the "majority adoption" phase.
Software is no exception.

Those problems appear because organizations are chaotic, in the mathematical
sense, in that the sum of the details completely eclipses the worth of any
idea. And that's an inherent problem.

------
logfromblammo
The problem with agile development has always been Agile Development.

Cargo-cult management practices freely adopted the brand facade without
embracing or even understanding the underlying principles that must be present
before the branded process elements can be good practice.

I don't care how good your process consultants are. They are not going to
convince any manager to reduce his own importance within the organization.
Just like it is much more difficult to make software secure by waiting until
version 2.0 to add it, it is harder to make an organization agile by patching
that in after the startup phase. It is far easier to be born agile than to
reorganize into it.

The failure comes when trying to convince a clumsy organization, with plenty
of vested interest in remaining that way, to become agile. What you end up
with is a racing stripe painted onto their t-shirts and shiny plastic spoilers
taped onto their asses, and no real improvement.

So in this context, GROWS will also fail. The only way to stop it from
happening is by the developers pushing back hard against any more brand-name
processes that are uncritically peddled to any organization flush enough to
pay a process consultant. Screw your new snake oil, buddy. My org listens to
me barely enough right now, and I don't need anyone messing that up with some
new kind of pointless meeting.

------
striking
I was on board with the article until he tried to sell me Agile 2.0. (an
unproven and confusing iteration, to make matters worse. Dreyfus skill model?
Nursing industry? I'll wait and see and hope someone else has some sort of
success with this before considering it myself)

~~~
Gigablah
I half-expected this article to be an elaborate troll =/

~~~
gtirloni
It started good and I thought it would get even better by creating a imaginary
new method (even with the "TM" sign) to make fun of the craziness it was
complaining about. At the end I didn't know if it was a joke or not but,
sadly, it looks it's no joke (to the authors, at least).

------
fat0wl
my company is "totally agile" (they wish) and it gives the management layer
something to do cuz they are analyzing JIRA all day coming up with horse-shit
charts, so of course they keep pushing all of it like its solving high-level
organizational issues in ways we will experience tangibly sometime by 2018...

if you got rid of all that process infrastructure and just had a few
programmers discussing proper design patterns now & then our company would be
lightyears ahead of where it is now. i think everything becomes cargo cult
when you refocus technical people onto processes that discourage technicality
to make management feel fuzzy about their stats. people aren't more productive
now, they are just gaming the agile system

process planning has its place i just feel like its becoming the focal point
of discussion rather than a means to it. bureaucracies will continue to grow,
what can you do other than look for a job with a more technical group that is
focused on code?

i'm a former academic, i was astronomically more productive in that setting
and there were no real process restrictions imposed at all. people need to be
cultured into code & self-education, not process. optimize process once there
is a good technical core in place, not in lieu of one

(i've also noticed that fake agile just promotes a lack of requirements docs
from business... in that case i'd be better off doing damn waterfall with a
half-decent reqs doc anyway...)

~~~
XorNot
Urgh Jira. Jira symbolizes the entire problem. Issue and task tracking where
the actual issue and tasks are 3 layers deep from the main interface, and
graphs and burn down charts are front and centre. It's all carefully
architected to appeal and sell to the managers who buy it, rather then the
dev's who use it.

Contrast to something like GitHub, where code is front and center, and issues
are a flat list and which has no other BS cluttering it up. Why? Because
GitHub _isn 't_ selling a product to managers first - it's selling to to dev's
first (via getting them in on open source).

~~~
CHY872
Jira has its moments, especially for larger teams. I've seen it used for large
projects, and there GitHub Issues would be garbage.

You can ditch a lot of the cruft from Jira by making your own dashboard etc.

------
aidenn0
In many martial arts there is the concept of 3 stages of learning that are
roughly[1]:

1) Learn a bunch of rules and follow them by rote

2) Learn when to break the rules

3) Learn to make your own rules

Looking up the Dreyfus model of skill development mentioned in the article,
there is a similar concept.

In martial arts, teaching at level #1 is easy; if person A knows a rule that
person B doesn't, then person B can teach it to person A. Similarly one person
can teach a large class of people a rule all at once. If you ever had a friend
as a kid do a year of e.g. Karate and say "Grab my wrist... No, not that way,
this way..." you've seen it taught at that level.

In martial arts, at least, learning above level 1 isn't really something that
scales, nor is it something that will easily happen without a lot of self-
motivation from the learner. There are, however, some traditions that are
successful in aiding someone in the transition in a sort of mentorship
relationship.

Such traditions aren't peculiar to martial arts though, as most crafts have
ways of doing it. It would be interesting to know if modern behavioral
sciences have found improvements, as the development of such traditions has
always been ad-hoc informal and more of "this is how my mentor did it" rather
than "we have good reason to think this way is best"

1: Here's an article on wikipedia about it; the martial-art I learned about
this was not Japanese, nor Chinese, so it was somewhat different:
[http://en.wikipedia.org/wiki/Shuhari](http://en.wikipedia.org/wiki/Shuhari)

------
lifeisstillgood
The essence of Agile and XP still stand tall

    
    
      - sit close to the customer (literally)
      - write good automated test coverage
      - release early and often and get feedback (see point 1)
    

If you are doing those three things, it's hard to totally fuck up. There is a
lot of process in making those things happen to be sure, but how that process
happens is not important.

the Agile Maifesto / Scrum tried to downplay process so much it became a by-
word for no process, and almost broke the good it was doing as no one could
track / report what was going on so every implementation looks like an
uncontrolled mess.

(Yes there were sticky notes up on boards, but it's hard to mail that to upper
management)

So a little more process, a lot more talking to end users and waaaaay more
automated tests and automated releases and we might have something

~~~
flurdy
Yes. Feedback!

Feedback from customers by iterating and releasing early and often.

Feedback from the team with proper frequent retrospectives.

Projects that I have been part of that skip or mangle retrospectives have all
struggled. Listen to the team. Keep tweaking, improving every week/sprint. But
keep the delta low so you can see what actually made an impact. And keep
retrospective to mostly the team only so root causes are actually mentioned
and not railroaded by external chiefs.

------
moron4hire
If we even look past the 15 years of Agile and into the 50+ years of big-
business software development, looking at the differences between the
organizations that succeed and the far, far more numerable organizations that
fail[1], then I don't think we see any differences that come close to touching
the technology or individual work habits of the employees. The differences we
see are organizations who trust their employees to be experts, and
organizations who try to manage top-down.

Centralized, authoritarian structures, whether for business or government, are
where the "lack of agility" come from that the Agile Manifesto spoke against.
Creating a new set of rules called "Agile" that such a centralized authority
can impose on its underlings doesn't change that.

[1] by some metric, either by time or budget or employee health and retention,
which is really just a failure of budget that has been paid for in a way that
doesn't show up on the accounting sheets.

------
aeturnum
Like most people, I've had mixed experiences with agile. I like short regular
meetings where I hear what people are doing - but not for process reasons -
it's just nice to hear. The places I've worked fit comfortably into one of two
categories.

In smaller shops, developers circumvent the process (whatever it is) when it
makes sense. Things are messy, but it's not so bad. Hard to say how much
process helps there.

In larger shops, the process has won and people just work around it.
Developers still try to get around the bad parts, but The Process is stronger
than any individual. Work seems to get done less, but everyone understands why
the work didn't happen. Generally, I get to go home earlier in these kinds of
environments.

All that said, a co-worker recently said they were excited to get more into
agile and linked a product that uses this chart to advertise their agile
tracking software:
[http://i.imgur.com/uYZwtFY.png](http://i.imgur.com/uYZwtFY.png) . I cannot
for the life of me figure out how we got from "people over process" to that
monstrosity.

------
bane
Ignoring the article for a moment. I think one of the problems with agile-in-
the-wild is that people who try to use it think in binary terms. In the
original manifesto, the idea put forth pretty clearly is about rebalancing the
way things are done -- not doing one thing instead of the other.

For example, it's not "Working software _instead of_ documentation" it's
"Working software over comprehensive documentation".

Agile should be a philosophy about development, not a set of rules.

To make matters worse, Agile-as-a-product (with Seminars, and Books and
whatever) seems to only amplify this. I've had scrum masters tell me very
directly that "the proper agile procedure for such and such is..." or things
very similar.

It doesn't mean you don't have tools or process or contracts or whatever...and
it's frustrating that most people don't seem to get that.

------
overgard
Agile is a very useful product.. for a certain target market.

The problem is that the target market isn't developers, and the product isn't
improved productivity.

The target is middle management, and the product is risk management. Or more
accurately, perceived risk management -- it doesn't really matter if it works,
the narrative of "being agile" is more important because that narrative can be
sold outside the group with all sorts of fancy charts showing just how well
managed things are.

That sounds cynical, but in a lot of ways it can be a good thing. Some
fictions really do have a utility. For instance, by creating measurables
(story points, etc), even if those measurable metrics are largely fictitious,
it can give a group credibility that will prevent interference from outside
stakeholders, and it can calm upper management that would otherwise be antsy.

------
bndr
There's an interesting discussion on
[http://www.reddit.com/r/programming/comments/354aze/the_fail...](http://www.reddit.com/r/programming/comments/354aze/the_failure_of_agile/)

------
Jgrubb
This _has_ to be a really late April Fools' joke. There is no way in hell they
could seriously be trying to pitch a "basically-new-agile-methodology" that is
this buzzword laden. I mean, the (TM) on the name?? Come on...

~~~
dragonwriter
Trademarking the name may be a way to prevent GROWS from being hijacked the
way Agile has been. The reference to the Dreyfus model makes me suspect that
(aside from rebooting to bypass the way Agile has been coopted) this may be an
attempt to put some concrete guidance into the metamethodology of developing
process in an Agile (in the Manifesto sense) organization, which was always a
fairly big gap in the Agile literature, which tended to be largely principles
plus the specific processes used by specific organization, without covering
how the _agility_ actually should work (though, if you got outside of the
Agile brand into works on Lean, which is pretty much the same set of
principles arrived at from a basis that has much stronger process engineering
background, and so tends to feature a lot more work on concrete methods of
process evaluation, there was quite a bit of that.)

------
raja4tech
I recently wrote an answer to a question on Quora about Agile.

[http://www.quora.com/Why-do-some-developers-at-strong-
compan...](http://www.quora.com/Why-do-some-developers-at-strong-companies-
like-Google-consider-Agile-development-to-be-nonsense/answer/Rajaraman-
Raghuraman)

To summarize my answers as to why developers have started hating Agile?

1\. Most organizations have a wrong understanding/implementation of Agile. 2\.
People especially at the management/leadership levels think that if a team
follows Scrum, they are Agile. 3\. There is an entire industry which is trying
to over exaggerate/misguide the Agile movement and make money out of it. 4\.
The troubled understanding that Agile is a One Size Fits All kinda thing. 5\.
Being in a Fixed Mindset (Anti-Agile). 6\. Some teams are already Agile. And
for them, Scrum should not be forced. 7\. Scrum by definition doesn't give a
damn to the seniority of engineers. Because everyone is a Scrum Team Member.
8\. Impediments are not removed. Or worse new impediments crop up when
implementing Agile in a bad fashion. 9\. Scrum by definition doesn't care
about flow state of a programmer.

And the essence of the article that I have just read is that there is gonnna
be a competitor for Scrum and it is called GROWS.. Wow.. Let's see what
happens next.

And as someone rightly pointed out, as long as there is corporatism which
tries to implement Agile, there will be lot of failures. So in a nutshell, it
is not the failure of Agile, but the failure of people who didn't understand
Agile properly.

------
kamaal
Agile only seems to be useful if you have prior exposure to the Waterfall
model, people who start off with Agile as their first software development
methodology tend to parse 'agile' as 'license to freely use bad practices'.
I've seen this often enough to a point, at times I think the older waterfall
model would work a lot better for a lot of shops.

Back in the day people would do a good deal of paper work as a part of
requirements gathering, this would iron out a lot of clarification and specify
clear definitions of what people wanted to do. These days 'define as you
code', often leads to getting requirements in piece meal, often adhoc with no
broader sense of design and what follows is endless refactoring. Delayed
projects, and rewrites.

One more damage agile is causing to the Google generation of programmers is
destroying skills related to reading and writing documentation. In a urge to
do everything in a hurry, we end up doing more damage than good.

And agile never quite really got rid of beaucracratic rituals of the waterfall
model, they just got re invented into their new forms.

------
YZF
The Agile Manifesto has a lot of good ideas and was motivated by real world
problems and how they were solved. The problem is like many other good ideas
is that they evaporate in a cultural vacuum. Agile methods like Scrum and XP
are based on the thought that introducing some rules can overcome culture.

What happens in practice is that culture subverts those rules in order to
reinforce itself.

Resistance to change is a stronger force than any buzzword methodology or
profound observations. This is further confounded by the very nature of
software development as something that can't be distilled into a set of rules.
Different situations require different approaches.

Is all lost? I don't think so. Agile has contributed to the way people think
about software development and gives the right team in the right culture more
tools they can use in the right situations. It's not going to "fix" software
development in general though.

------
rossng
If GROWS became popular, it would also be 'sloganized', branded and ruined.
People would go to one-day intensive GROWS courses, get certified and then
just do waterfall anyway - exactly what's happened to Scrum and everything
else.

I find it slightly ironic that they (correctly) say they are no silver
bullets, then suggest a silver bullet.

~~~
pkaye
I don't know anyone who just does waterfall anyway except for simple projects.
You just can't get all you architecture and design done up front. There is a
lot of iteration between architecture, design and coding. Requirements change
and things need to adapt. That is not waterfall.

~~~
chiph
Lots of places do agile-washed waterfall.

They're mostly places that look for a methodology-in-a-box type solutions.

------
backtoyoujim
I think that I left software development just as these schemes where becoming
en vogue.

Being on the outside of the industry and reading about all of these acronyms
of "how to succeed with great apes" ... it reminds me of being in middle
school band. It smells like how first chair worked to get all of us clarinets
to practice more and to try to out do each other performance-wise.

It works.

But eventually it changes from first chair to "first chair". And then it
became, iirc, a lighting-rod for interpersonal problems amongst the single-
reeds that became disruptive.

I suppose that I think of these schemes as MBA-encoded first chair politics.
They work while the meta-game is immature. But as soon as players get to see
the carrot for what it is ... it is all about a competition for who gets to
hold the stick.

~~~
ArkyBeagle
It's funny - as a former French Horn player, the second horns get all the good
parts...

I've been political, I have been apolitical, I've been places where there were
no politics. In the end, it's all the same.

------
zhte415
Agile is great, for many reasons. Not least but including:

Having loads and loads of meetings. Like teaching people to build a car or
town with Lego using an Agile methodology. Instead of letting them do it
themselves, it was a game-changer on memories of Lego as a kid, the impact was
like coming off a waterfall, no, even being in a waterfall.

Improving meetings by doing them standing up with a whiteboards instead of a
meeting room glassboard. Not only freeing up precious meeting room space for
those teams doing scrums with remote teams that also do stand-up whiteboard
scrums on their own, our white boards cost leading to less wear-and-tear,
scrums tend to last for 30-60 minutes, improving everyone's cardiovascular
system, and we can do them at any time of the day whenever the team lead
decides a scrum should be done, damn everyone's productivity, it is all about
the scrum and helping everyone get things done. My team lead says Agile is a
better method for managing things.

Overtime is now referred to as a 'sprint' when we realize we're behind
deadline, but can enjoy the process of sprinting every 2 weeks. We have
replaced the boring, planned methodology of milestones and working overtime to
fix what we hadn't planned by sprints, where we do overtime on a
systematically planned 2-times-per-month basis, and everyone is happy because
of the 'focus time' whenever we're not scrumming, and free taxi home at night.
We also work shift 2 days per week because that totally helps sleep patterns.
Enjoy the early morning and late evening at least twice per month.

If the sprint doesn't work, we just push things to the next release. It seems
to keep everyone happy.

Agile tools are so flexible we have to make our own, as our organization is so
paranoid and locked-down regarding information security we cannot use anything
that doesn't go through an approval chain so many miles long it literally
virtually circles the earth several times over. So we resist this, and
dedicate 1/4 of all of our resources to beating these out-of-date systems at
their own game. A guy said he could do the whole 300 person project in Excel,
but we thought maintaining a staff Name-ID-email-telephone table would not
totally not work, and kept the 300 people making this system Agile instead,
we're just using a single API, after all. Agile is all about the team.

Even our bathroom staff are Agile. When the GM leaves in the evening, all
tissue paper is removed from the bathroom, promptly. It is replaced when he
returns in the morning. That is keeping a tight, ship.

*All the above is true, if somewhat hastily typed.

------
fr0styMatt1
The Agile manifesto was originally written, from what I understand, by people
who actually understood software.

I just don't understand what logic brought us to this place where it's not
seen as weird that someone wholly non-technical and unfamiliar with software
can be a manager of a software team (or run a software company, for that
matter).

I'm not arguing that software is somehow 'special' either - I'd make the same
argument if say, for example, someone wholly unfamiliar with steel fabrication
was acting as a factory foreman. Or if me, as a software guy, decided to just
one day declare that I'm qualified to successfully manage a farm.

I feel like this is a big part of the problem. Not the whole problem, but a
big ccontributor.

~~~
dragonwriter
> I just don't understand what logic brought us to this place where it's not
> seen as weird that someone wholly non-technical and unfamiliar with software
> can be a manager of a software team (or run a software company, for that
> matter).

"Brought us to this place"? We've always been in that place. In the last few
decades, we might have started inching _away_ from it a little bit, we
certainly haven't recently arrived at it.

The idea that leadership of an technical organization should be skilled
technicians (at least up to the point in the organization where there is a
distinctly technical organization) is something that has _never_ been the
dominant wisdom in business ("management" as a distinct and transferrable
skill set has been more dominant.)

Certainly Lean Software Development (and its direct predecessor in Lean
Manufacturing and some of the other things that fed into Lean Manufacturing)
tend to hold the position that leadership in a technical organization should
be technical, but while that Lean has become powerful in some areas of
manufacturing, its never been dominant in software development or business
generally.

------
CodexArcanum
I feel like someone should develop and market the "I Ching" and the "Tao te
Ching" as a development methodology. It could attain the same cultural
position that "The Art of War" enjoys in business.

> Chapter 54

> That which is well established cannot be uprooted

> That which is strongly held cannot be taken

> The descendants will commemorate it forever

Here, the classic teaches us that strong coupling incurs technical debt which
limits the future of the application. Just because we've always done it this
way, doesn't mean you must rigidly follow bad methodology.

Plus, the inclusion of I Ching divination provides a built in means of making
easy decisions and resolving conflicts.

------
lessthunk
agile per se is good -- making it a religious is ususally bad;

I saw many companies using scrum and often I felt like this is a process for
slower moving teams, instead of the opposite;

Great software is being written by great individuals that move it forward,
pretty indecent of whatever process a company tries to use. To me a process
must not get in the way or productivity and creativity.

------
omouse
The problem with Agile is that it's political; it gives programmers lots of
power because it allows them to control the scope of the project and it gives
the more access to the client/customer/business analyst/user. It also lets
them argue for improving quality through test-driven development and pair
programming.

When you have a manager, a marketing department, you have multiple points of
power where the manager(s) come first and try to control everything. Giving up
that control is difficult to do. When you have a marketing department, they
assume they know what is best for the user and what features the user needs
and at what time (all the features done by day X). The developer ends up being
a code monkey who's hired to implement exactly what some MBA (or even worse,
non-MBA!) wants. It doesn't even matter if users hate; it doesn't matter how
slow it is, as long as it meets the whims of the managers in charge.

With Agile, you get rid of the bureaucracy and you make the feedback cycle
faster and you have quality built-in. You don't really need marketing or a
manager calling the shots because you can go to the customer directly (or
through the customer proxy who also is with your agile team every single day).
You've effectively removed one or two jobs or at least reduced them to part-
time work; that's very dangerous in a hierarchy.

Programmers are low status; when we're high status we can have Agile and we
can influence the work we do.

------
InclinedPlane
Process is valuable, but too often people fall into the trap of trying to
trust everything to process. Which will never work. A process is like a little
code snippet. The best processes involve heuristics which complement the
experience and judgment of human beings in the loop. Otherwise you just get a
kafkaesque nightmare.

Agile has some special additional problems, including a misleading sense of
detail, a tendency towards short-sightedness, and misplaced credit for success
on the process. Having a ton of "artifacts" or stats doesn't mean you have the
_right_ data, or even enough data, but if you have a lot of interesting data
you tend to fall into the trap of believing you know everything. Agile's short
planning windows often means that you don't get proper credit for long, drawn
out work and planning very far ahead. This is actually intentional, as
Agile/SCRUM have been designed to get productivity out of unproductive and
dysfunctional teams, but sometimes you need more than just stumbling along.
Also, because Agile has a lot of detail to it people tend to give it credit
for successes due to the post hoc fallacy (e.g. "we did Agile, and then we
shipped a great product, yay Agile!").

------
neilk
I think the conclusion is telling:

> And finally, whatever we attempt here has to work for the whole system, not
> just the developers, not just the managers, not just the testers, not just
> the users, not just the sponsors. There is no ”us” versus ”them.” There is
> only us.

The goal in all these methodologies is to get everybody so perfectly aligned,
they'll naturally zero in on The Right Thing.

But the people who are really in charge have no intention of ever letting this
happen. It doesn't matter what the methodology is.

People try to apply Agile or whatever in the modern American corporate
environment, which is a seething pit of fear and mistrust with no job
security. So everyone wants harder guarantees. Brighter lines, that show if
they've done their job well or not.

So despite their best intentions, there are strong incentives to _maintain_
all the anti-agility boundaries, in order that blame and credit flow to the
appropriate people. If there was a truly Agile product that succeeded, who is
to be rewarded? It's hard to say. If it failed, who is to be blamed?
Everybody? Nobody?

This isn't short-sightedness -- this is purely rational. This is why you get
"Agile"... plus hard requirements docs... hammered out in advance... and a
waterfall schedule.

------
ThomPete
The problem with agile is that it requires a completely different way to think
about productivity and company finances not just in the team but the entire
connected reality of a project.

Agile solves a conceptual issue which is it creates a more effective feedback
loop that keeps everyone more informed than they used to be with classic
waterfall models.

The problem though is that the financial reality isn't following the logic of
the agile model and so whether you are trying to use the agile model for
customer projects or internally in your organization you are still a child of
the the overarching financial reality which dictates how companies are
measured and budgets created.

Agile is great for innovation where there is no deadline and no limited
budgets. It creates a false sense of effectiveness when it comes to projects
with deadlines and budgets.

At the end of the day all it does is allow you to say earlier to those you
have to deliver to that they aren't going to get everything they asked for at
the same price as what they thought they were getting.

~~~
janee
> "Agile is great for innovation where there is no deadline and no limited
> budgets"

that rings very true with me. I'm nearing the end of a 3 year project where
scrum was prescribed and followed, but the truth is we've basically shoehorned
agile practices into a waterfall model because of business needs.

My experience with agile projects is probably far removed from how it should
be implemented, but it still feels like it's fundamentally flawed to address
business needs which rely on fixed scope and accurate estimates from the start
of the project succeed (e.g. critical 3rd party tools being end-of-lifed,
product mandates beyond company control, renewing client licenses based on
feature completion).

I guess until something better comes along, I'm stuck with being told to do
some strange type of scrumfall/water-gile.

------
uxcn
Even Dave Thomas (another original signatory) has admitted there are serious
problems with the way agile is generally practiced.

[http://www.drdobbs.com/architecture-and-design/dave-
thomas-i...](http://www.drdobbs.com/architecture-and-design/dave-thomas-
interview-the-corruption-of/240166688)

~~~
bananaboy
Yeah Dave Thomas has written about it here too
[http://pragdave.me/blog/2014/03/04/time-to-kill-
agile/](http://pragdave.me/blog/2014/03/04/time-to-kill-agile/) and also Mike
Cohn one of the developers of scrum has criticised blindly following
methodologies (which is sort of related)
[http://www.mountaingoatsoftware.com/blog/dont-blindly-
follow](http://www.mountaingoatsoftware.com/blog/dont-blindly-follow)

~~~
uxcn
I think the fault was that they focused more on codifying approaches to deal
with specific problems rather than discussing the problems they address, and
encouraging people to recognize those rather than take a specific approach.

The manifesto was nearly a ten commandments of software development.

------
snarfy
Agile as practiced by the industry is nothing more than a way for
dysfunctional businesses to punish their developers.

------
arenaninja
Over on [http://growsmethod.com/](http://growsmethod.com/), when you sign up
for the mailing list, the page confirming your subscription is loading in
mixed content (JS!). I'm suddenly not inspired.

That said, I don't see the point of "methods", agile, waterfall or otherwise.
When I worked building SaaS for school districts, we shipped roughly once a
month, so I guess that was waterfall, but some ideas we iterated multiple
times within that ship period until we liked one. Now I work with a set of
e-commerce websites, and nothing front-end isn't AB tested (which slows down
shipping anything), and new backend functionality is iterated almost daily.
But I've never called these methods anything other than the right approach
based on the situation.

------
djb_hackernews
The proposed solution feels good and all but in my experience it would be
almost impossible to adopt for most companies operating in VC-istan.

The most extreme case I can think of was a "startup" I worked at that was VC'd
to the gills, had an impressive board, with no traction, no revenue and about
25 engineers on staff. What they did was what I liked to call "product
development by whim" where they had 5 product managers which each got to
decide which features they wanted and the devs went and built it (we really
really really needed a way for our non existent users to invite their friends
via email, etc).

So if we needed evidence before development the whole house of cards would
come falling down because the evidence would have shown no one wanted what we
were selling, period.

------
strommen
The reason that BigCo never does capital-A Agile is that their release dates
are fixed months ahead of time (to coordinate across the organization), and
they want to know what they'll actually be shipping in 6 months (again, to
coordinate across the org). This makes the biggest two selling points of Agile
- continuous release and rapid change - completely worthless.

The only model I've actually seen in a large organization is for the dev team
to throw together a barely-working prototype, then spend the next 6 months
fixing all its problems while the Marketing, Sales, and Customer Service
departments train up on the new software. And they'll find a way to call this
"agile", because otherwise the developers will revolt.

------
Yhippa
Is it April 1? Andy poo-talks Agile and then drops GROWS (TM) on us? You have
got to be kidding me.

It's been mentioned on here a lot that if you have a skilled set of
programmers on your team you probably don't need Agile. They are self-managed
and tend to do the Right Thing (TM) on their own.

I have seen Agile work and when it does it's pretty fun. Things move along,
issues are dealt with, and nobody panics when things get behind a little. Just
move it to the next release.

I think the problem is that The Consultants sold Agile to enterprise dev shops
and they really ate it up. I don't feel Agile works from the top-down but
rather organically from the bottom-up. In fact I believe that is true for most
programming methodologies like this.

And Scrum. Don't get me started on Scrum.

~~~
tablet
> if you have a skilled set of programmers on your team you probably don't
> need Agile

This. Craft and passion beat any process. These people will organize
themselves into the most efficient process eventually.

~~~
matthewmacleod
_This. Craft and passion beat any process. These people will organize
themselves into the most efficient process eventually._

My direct experience of working with programmers over the years is that this
will generally descend rapidly into an inefficient mess. Yes – maybe it works,
sometimes. I'd argue that's the exception, rather than the rule.

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

If you work with people who dont care, youre screwed. Nothing will ever work
to force them to actively engage with the process of creating good software.

..but, surprisingly, when you _do_ work with people who _do_ care, they self
organize remarkably well. The Valve megacorporation is fundamentally based on
this. It works. Thats been _my_ personal experience, over the years.

The problem that has to be addressed is convincing people to care, and self
improve.

Forcing a process on the unwilling is going to fail no matter what you do.

~~~
matthewmacleod
I agree that a group of people who don't care will almost always produce
substandard results.

I don't agree that people who do care necessarily self-organise well, or that
this self-organisation is compatible with other business goals.

Sometimes it works, and a group of engineers et al. do a good job of forming a
coherent team with minimal process. Valve's maybe an example – I don't know.
My experience is that this is the exception, rather than the common case.

A good process can provide tools that help good people who care communicate
and deliver more effectively. They help us to keep track of how we're
performing and analyse pain points, and to make sure that there are methods
for dealing with common problems.

For example, if my team felt that daily stand-ups were an inconvenience that
weren't helpful, then we wouldn't do them. That's the goal; there's no cast-
iron set of rules, just a generally applicable set of principles to follow.

~~~
philippeback
Some kicks in the assets and firing bad apples also go a long way in keeping
the team focused.

Some people are self motivated and other needs their slap in the morning (for
some, that's a couple of times daily).

~~~
rpcope1
You know, I probably don't know as much as you do, but every time I've ever
seen lots of negative reinforcement get applied to teams both in software and
outside, it seems to have the opposite effect. Sometimes you have to quietly
handle the most toxic people, but on the whole, when you take this sort of
approach to managing, I would be very surprised if you only make the situation
drastically worse in the long run.

------
icc97
It really, apparently, isn't a joke:
[https://twitter.com/growsmethod/status/596404929679458304](https://twitter.com/growsmethod/status/596404929679458304)

------
sandofsky
I've found Agile to be a collection of useful tools, but just like
"opinionated" framework, it's only perfect for solving the author's problems.
In my experience, agile works better for web apps than native mobile apps.

What worries me is toxic dogma. Too many Agile people say:

* "Agile failed? They weren't practicing it correctly!" a.k.a. the "No True Scotsman" fallacy * "You have to choose between Waterfall and Agile" a.k.a. the "Black and White" fallacy.

I realize that not all agile people are like this, but there are enough vocal
members of the community that it reminds me of religious fundamentalism.

------
snarfy
I've seen Agile work, except it wasn't called Agile, and it was before Agile
existed.

At a small game studio, you may have one guy that knows the hardware really
well at a low level, but not the engine or how it's used, but the engine
developer does. When you put these two guys in a room together, they will
crank out something beautiful in an amazing amount of time, something neither
of them could have accomplished alone.

That's agile. Not whatever crap the current mantra is. The manifesto gets
this, but it never should have been made into a process.

------
frabcus
A key thing not mentioned in the article or the comments, is that agile only
works for certain _kinds_ of software (when the software category is still
being custom built).

For others (when the software category has become a commodity), waterfall
methods like six sigma are better.

Simon Wardley is great on this:

[http://blog.gardeviance.org/2014/07/agile-agile-
everywhere.h...](http://blog.gardeviance.org/2014/07/agile-agile-
everywhere.html)

------
spiralpolitik
Agile fails at most companies because they fail to understand that Agile is a
culture not a process. Take the first statement of the manifesto, to allow the
individuals to interact you have devolve responsibility down to the level
where individuals can make decisions without having to run it up the ladder.

This scares the crap out of alpha executives and so they throw process and
tools to ensure that the individuals interact in the "correct" way defeating
the whole effort.

~~~
hibbelig
You're describing this:

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

------
yellowapple
> GROWS in this case is an acronym, for GRowing Real-World Oriented Working
> Systems

Why emphasize the R in GRowing when the R for GROWS could have been taken from
"Real-world"?

------
carsongross
Uh oh, The Client is figuring out that Agile isn't a silver bullet for
building great software... Time to turn the crank..

Get your team GROWS™ certified today!

------
mikmoila
It looks like all sw development processes try to guarantee budget by taming
"unanticipated change". Unfortunately this can't be planned or taken into
account early enough, by the definition of "unanticipated". Some processes are
better in avoiding collateral damages when trying to restore the budget than
others, but at the end of the day, we have a change in our hands.

------
4ydx
People can call these things whatever they like: there is a difference between
passion and indifference that cannot be overcome by any process.

------
DataPrivacy
"Agile methods ask practitioners to think, and frankly, that‘s a hard sell."

Wonderful point, and spot-on. But that's not just for agile newbies, I'd
extend that to other groups that are immersed in something. The best example I
can think of at the moment are MBAs. For whatever reason, smart people go off
to charm school, earn their MBA, and then forget how to think.

------
chiph
I've been at one place where agile/scrum worked. None of us were superstar 10x
developers. What made it work was that we had a lot of trust between the
developers and management. And that we knew the code-base well enough to be
able to give accurate estimates (low turnover is good that way).

------
grantph
It sounds like Andy Hunt has finally discovered ISO 9000. Plan. Implement.
Measure. Review. Improve.

The pattern I keep seeing is the IT community's need to re-invent the wheel
and give it names like 'agile', 'scrum', etc. Why can't people call a wheel a
wheel?

------
nilkn
It appears this is less about agile and more about some new... thing... called
GROWS:

[http://growsmethod.com/](http://growsmethod.com/)

I can't figure out what it is, though. Then again, I never figured out what
agile is either.

------
Fr0styMatt8
Relevant talk by 'Uncle Bob' about how Scrum became what it is now, as opposed
to what it was intended to be:

[https://www.youtube.com/watch?v=hG4LH6P8Syk](https://www.youtube.com/watch?v=hG4LH6P8Syk)

------
nyddle
I think methodologies in general don't work as they are basically someone's
reflection on some process (ex. Lean Startup by Eric Ries), an attempt to
generalize one's experience that isn't widely applicable by construction.

------
emodendroket
The new agile manifesto:

1\. You're doing agile wrong.

2\. If you pay me I can make it so you're doing agile right.

------
darkxanthos
Is a "new Agile" really what will solve this problem? I think really this just
isn't a priority for many employers. Maybe we just need something new so us
employees can see who's paying attention and flock there?

------
simula67
Relevant : [http://pragdave.me/blog/2014/03/04/time-to-kill-
agile/](http://pragdave.me/blog/2014/03/04/time-to-kill-agile/)

------
einrealist
Agile cannot fail. People fail. People will fail at whatever process or method
for various reasons. At least Agile methods embrace failure and demand
adaption or change in order to become successful again.

~~~
ExpiredLink
> _Agile cannot fail. People fail._

a.k.a self immunization

------
wiradikusuma
while we're in this discussion, is there any good hosted agile/scrum tool?
(note: asana doesn't seem to count, it's too flexible, like a glorified todo
app).

if there isn't any, i'd take this as an opportunity to develop one (i recently
acquired agile.id and scrum.id domain, otherwise i'll just sell the domains).

...or maybe because their mantra "people over process" so the practitioners
never feel the need of management software?

------
joubert
process is often the symptom of tight coupling.

~~~
ukigumo
That sounds really strange to me, to the point that I'm not sure if you are
being sarcastic.

~~~
marcosdumay
Sarcastic or not, it's true.

I mean, it's completely tautological; conveys no useful information, and must
be fully understood before acting over it in any way.

It's also funny. I'm upvoting :)

------
copsarebastards
"Agile process" is an oxymoron. Agile hasn't failed, process has.

------
icc97
GROWS (TM) sounds like another Scrum instead of being another Agile.

------
sutro
If any of you would like to learn more about GROWS™, I have started a GROWS™
consultancy, and I am also offering a GROWS™ certification process. My GROWS™
stands for God-awful Regurgitation Of Weak-ass Snakeoil. These seem like
important concepts.

------
irrigation
Any discussion about agile invariably yields the predictable flurry of
personal hangups and misrepresentations.

Most common of all, though, are the claims that if you just have a great team
full of great developers, you don't need a process. Agile and waterfall both
be damned.

But most teams aren't great. Most of the teams of people participating on HN
statistically aren't great. But those teams still need to develop something --
banks and big cos and countless firms are churning out code by the millions of
lines, by millions of completely average developers -- and agile is an honest
conclusion that the classic method of software development doesn't work, most
critically by biting off work in such enormous chunks that implementation or
design issues -- the fit to the problem -- aren't discovered until enormous
efforts have been wasted.

So talk about how agile failed, in your estimation, at some shop or another.
But the truth is that almost anything would be a "failure" versus the
idealized notion of a perfect design built expertly by great developers. Agile
is trying to make the best of a normal situation.

~~~
LordHumungous
None of the people who complain about agile offer any viable alternatives. I
get the impression that these are developers who simply hate being managed
period, and would prefer that management never spoke to them at all.

~~~
yxhuvud
I certainly wouldn't mind if the middle manager that had an hour long meeting
today never spoke to me again. The first slide was MLK with "I have a dream"
which then continued onwards with 15 minutes talking about how to move post-it
stickers on a whiteboard and 15 minutes spent doing a failed analogy between a
GPS and continuous reevaluation of when the next release will be done.

At the same time, management has decided to have a release cycle that is 10
months (or in reality after the inevitable delays: 12)..

------
oldmanjay
the thing that often gets lost in these discussions is that a software
development process is mainly a method of communicating state to management.
management does need to know, despite developer complaints, because company
resources need to be allocated and tracked.

if developers can't figure how to let management get the information they
need, then management will impose whatever they think is best, even if they
have no particular way of figuring that out.

the failure of agile is mainly a breakdown in this communication. the process
itself works if it is followed, just as lighter and heavier processes can
work. are they optimal? probably not, but communication amongst teams is a
fairly difficult problem to optimize and it's likely to not have any one
solution.

------
joesmo
I've worked at over a dozen places claiming to be agile to some degree, shape,
or form, and have yet to see a process that's even remotely close, let alone
agile. The failure of agile isn't that it takes time to learn and practice
correctly or that it's too rigid. Its main failure is an inability to
communicate its purpose to its users effectively. Agile is a good process in
theory, but it seems the original creators did not anticipate the people that
would try to put it into place and their agendas.

Agile goes against the mandates of almost all corporate culture in that it
requires one to get out of the estimates as deadline mindset that rules
corporate development. Agile tries to be flexible because that's the only
rational option when developing software. When faced with irrationality,
however, agile just becomes another justification for deadlines, time-wasting
meetings (standup and otherwise), and other nonsense that leads to a
productivity plunge everywhere I've seen it implemented.

This corporate culture based around deadlines and subservience of engineers is
something that cannot simply be defeated with a methodology, especially when
that methodology is, at best, only partially adopted. I will go as far to say
that there is no methodology that can change this mindset. Regardless of what
the author thinks, corporations and their managers will simply not allow
something that will disrupt their world views and opinions.

While agile was trying to solve the problem of waterfall design--which is not
always a problem and sometimes the best process--many corporate schmucks (both
in management and engineering, both at giant companies and startups) saw it as
a way to eliminate the design stage altogether. What great software has
resulted! While agile was pushing for quicker iteration and release cycles so
that code and features doesn't pile up and prevent / delay / disrupt the
release, many corporate schmucks (managers only in this case) decided to use
it as a justification for working their engineers overtime so they could push
the features they "promised" out live by the release date.

There are few things in this industry that have wasted as much time as the
doomed implementation of agile. Many have gotten rich off of it, but it has
provided little to no value. The idea that processes can be malleable and
flexible that the author advances is just pure insanity. It may work with a
group of hackers cranking something out, but something like that will
especially be discarded or twisted into something dark by management.

This idea, that a perfectly good process can be turned against itself is what
the author does not understand and why his new process will likely fail in the
same, dangerous way (should it gain acceptance and adoption), wreaking havoc
on the engineers and managers it was supposed to help.

------
michaelochurch
Agile glorifies treading water, which will sometimes save your life, but won't
get you anywhere. The problem is that it discourages actually swimming, and
people forget how.

To explain: where this sort of project management actually works is in a
short-term, time-limited crisis that large companies might call a "Code Red"
or (in the original meaning of the word) a Scrum. See my Quora post on the
topic: [http://www.quora.com/Why-do-some-developers-at-strong-
compan...](http://www.quora.com/Why-do-some-developers-at-strong-companies-
like-Google-consider-Agile-development-to-be-nonsense/answer/Michael-O-Church)

When you're a small web consultancy that has landed a make-or-break project
that (say) must be delivered inside of 4 weeks, and when you have absolutely
no leverage and must accept any changes in scope as they come, Agile can work.
You can reasonably expect people to set aside their long-term goals (career
progress, tech debt reduction) and solve the problem at hand. Moreover, when
you're a big company fighting a Code Red (meaning, money is being lost right
now in large amounts) and have to assemble a cross-cutting do-nothing-else-
for-now team with no clear manager, Scrum can actually make sense.

In a true sprint-- a short-term reorganization necessary to solve an immediate
problem-- unsustainable effort is OK because, well, no one's going to be
expected to sustain it. You're under a short term emergency. You can ignore
whether the assigned work helps peoples' careers, because they're not going to
be doing it for long. You can mandate that people work on the "official" top
priority (of which there's only one) and most people will do so.

The problem is the perma-Scrum that's been sold (dishonestly) by the Agile
industry. This stuff works for a few weeks and people don't mind doing it. In
fact, even if the work itself is painful and the hours are bad and status
updates are (by necessity) frequently demanded, being tapped for the "elite
emergency team" is something that people generally like and, over a span of 2
to 6 weeks, it gets results. However, when you have permanent "sprinting" and
frequent status meetings or impose these rules over the whole organization, it
starts to hurt morale. It starts to feel less like being on an elite emergency
team and more like a culture of permanent juniority/micromanagement... which
is what Scrum/Agile has become in many organizations.

~~~
lowbloodsugar
You're saying that Scrum and Agile promote long hours? What does "sprinting"
mean?

~~~
michaelochurch
Long hours are just one variety of unsustainable practice. Accumulation of
technical debt, and an absence of concern for individuals' career needs and
goals, are likewise acceptable in the context of a short-term emergency but
not sustainable.

In perma-Scrum terminology, though, the end of one sprint leads straight into
the next. This is the core problem with Agile/Scrum as it's sold: it takes
behaviors that are known to be unsustainable and encourages people to carry
them permanently, and then says they're not doing them right (No True
Scrumsmen) if the arrangement deteriorates. It can't be sold truthfully, as a
short-term fix that does a lot of damage if it stays in place for too long--
no one would buy it if it were advertised as something that only works for 6
weeks, max, out of a given year-- so the Agilemongers present it as a
permanent arrangement.

~~~
lowbloodsugar
I think you are confused. A "sprint" is not "crunch". Its not a period where
we work our asses off, late hours, weekends etc. A sprint is just a period of
time. For us its two, forty hour weeks. Its sustainable and we've been doing
it for 16 months.

It leads to a very confusing situation, where on the one hand the team is
lauded for being the most productive team in the company, and on the other,
for not working hard enough. o_0

If you can find anything in any Scrum publication that says otherwise then you
can make the No True Scotsman claim, but otherwise you are at best
misinformed.

