
The End of Agile: Death by Over-Simplification - ern
http://effectivesoftwaredesign.com/2014/03/17/the-end-of-agile-death-by-over-simplification/
======
lostcolony
Agile requires a bit of fudging around the edges, but it already admits that
that is required (people > processes).

Yeah, YAGNI and its ilk may apply, but sometimes you -do know you're going to
need it-. That story is in the pipeline, your users are demanding it; to
design and code only to the current story, dismissing the design
considerations that that future story would impose upon the current one, is
shortsighted and self-defeating. You shouldn't be delivering -features- from
that story yet, but by all means recognize that "Oh, we'll need a hook for
that, and it would make sense for me to implement this with an event manager
so we can add subscribers, and keep these decoupled, rather than just make a
direct method invocation", etc, so you can easily tackle that future story
when it comes up.

Oh, hey, the build and deploy process sucks, and that has no direct user
value, and thus no story. Well, deal with it anyway; you -know- that is
costing you time, and being able to rapidly iterate = faster development time
= less cost = desirable to the user.

Etc.

Really, agile always seemed to me to be two different things. One was a series
of processes. The other was a series of values (among which was people >
processes). And a lot of the flack agile has taken recently has been due to
people focusing on what happens when teams adhere rigidly to the processes, to
the detriment of the values, when it should be the other way around.

EDIT: I've also seen teams that take the values as excuses to ignore the
processes, which also fails hard. "People over processes? Okay, no process
then, everyone just code! Get shit done!" The point is to take on the
processes, modify them in accordance with the values as experience leads you.
Something doesn't work for your team? Change it. As someone mentioned
elsewhere on this thread, that's what retrospectives are for.

~~~
tbrownaw
_And a lot of the flack agile has taken recently has been due to people
focusing on what happens when teams adhere rigidly to the processes, to the
detriment of the values, when it should be the other way around._

The problem is, that's how it's being sold. The perfect Platonic "Agile" may
not have strict processes, but the in-practice "Agile" that comes with
consultants and certifications and marketing _does_.

~~~
dragonwriter
> The perfect Platonic "Agile" may not have strict processes, but the in-
> practice "Agile" that comes with consultants and certifications and
> marketing does.

If you are substituting reliance on marketers and consultants selling canned
processes telling you what to do instead of your engineers developing their
own knowledge of what Agile is and applying it, then, yes, you will get some
canned thing sold by marketers and consultants that has an "Agile" label stuck
on it but which is the exact opposite of what Agile is -- since any canned,
externally-defined, process sold across the industry by marketers and
consultants is not only "not Agile", but exactly the problem that Agile was
defined to solve.

OTOH, that's not a problem with Agile, that's a problem with outsourcing the
basic function of engineering your own internal processes without developing
internal understanding.

~~~
dllthomas
In an environment where employees stay with a single company long enough,
consultants may be a valuable way of moving information between companies. I'm
skeptical that much software development work sufficiently resembles that,
though.

------
scottlilly
I think that one problem has been with some people promoting TDD by saying to
write "the simplest thing possible to get the unit test to pass".

I've seen "Uncle Bob" do his bowling game demo, without using the expected
classes for Game, Frame, etc. It's an interesting exercise, but would be a
horrible way to write any large-scale business application. However, some
people walk away from that with the idea that they should write quick "hacky"
code, instead of doing any thinking about design.

When I write a program, I use my [constantly-evolving] set of "best
practices", based on what I've experienced when writing other applications.
Writing a factory method for object instantiation is not "the simplest thing
possible", but I've seen it come in very handy at times, so that's what I'm
doing in my projects now.

After all, aren't retrospectives, and modifying your process based on what
you've learned during your project, one of the huge points of Agile - even
though I've rarely seen them done, let alone done well.

~~~
cageface
This is a classic and hilarious series of posts on the foolhardiness of the
TDD approach to software design:

[http://devgrind.com/2007/04/25/how-to-not-solve-a-
sudoku/](http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/)

Personally I prefer Rich Hickey's "Hammock Driven Development":

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

------
markbnj
As someone who has been programming for a living for a couple of decades now I
have seen more than one methodology come along and propose to solve all the
"problems" with my craft. Like any young discipline we still have a lot of
things to work out, however I find that as I get older I have less tolerance
for the view that "the problem" lies in the way programmers do things. I think
rather that "the problem" lies in the way customers treat the process of
creating software. They approach it with a casualness and an indecisiveness
which would not work in any other context where something expensive and custom
was being built from scratch. I can honestly say that in over twenty years I
have not been acquainted with a project that failed because the people who
were responsible for writing the code couldn't get it done, or couldn't get it
done fast enough. On the other hand I've seen lots of projects fail due to
inadequate executive commitment, off-the-cuff estimates, evolving feature
sets, etc.

~~~
cageface
I agree with this but I think at least part of the problem is that we don't
have good tools for specifying precisely what it is we intend to build. If we
could create software plans as detailed and exacting as blueprints for a new
building we'd have far fewer failures. Instead we toss together a few
wireframes and start hacking and by the time we're done the final product is
nothing like what we were originally tasked to build.

As far as I can tell this just isn't the case in any other field of
"engineering".

~~~
markbnj
Perhaps, but how useful are those detailed plans and blueprints to the actual
consumer of the construction service? They get studied, sure, but I think the
customer is still working at the level of features and their expression in the
plan, not the plans themselves which are more of an internal tool for the
architect and builders. It's true that we lack widely accepted formalized
design tools like blueprints, but at the same time it's interesting to note
that one of the recognized problems with extensive planning and design
documentation in software is that it can't keep up with evolving requirements
:). So again, we can't plan because the customer has been taught to think
everything is open for discussion at all times.

~~~
cageface
I agree that client requirement sculpting is a major issue. But I think if we
could give them something like the kind of detailed 3d walkthrough that's
possible now in architecture, for example, we could possibly also get them to
agree that no significant changes will be made once they've signed off on the
plan. I have no idea how this could actually be done though. So many of the
implementation details are opaque to any non-technical client.

------
JoeAltmaier
User stories work when the user interacts with every part of the system. But
for backends or libraries or engines, there is no user but other developers.
We're not trying to delight developers probably, but to enable them. That
different impulse drives different coding behaviours/ project plans than 'put
up another screen for the web user'.

I disagree that technical debt == bad code. That's just a cop out. Code can be
golden and still not cover all the cases or perform as well as a better-but-
larger-effort solution. So we cut corners, write golden but small-scale code
and move on. Its a startup after all. Then later when the fires are out and we
have time to breath, we'd like to spend 12 hours and put in more golden code,
that takes longer to develop but performs better or covers more cases.

------
adamors
> In my personal opinion, we will have to go back to the basics: To all the
> wonderful design fundamentals that were being discussed in the 90’s: the
> SOLID principles of OOD, design patterns, software reuse, component-based
> software development.

Many of us are doing just this while practicing Agile. It's not an either or
situation. Are people really this out of touch with contemporary software
development practices?

~~~
BSousa
From experience, not many, a few.

Worked with a good bunch of developers that didn't even know SOLID existed
(but what do you expect when developers now a days have a 30 day bootcamp or
read a Rails book and are able to get developer jobs?)

------
planetjones
Fair points, for the most part I think. To write good software, you need good
people who know what they're doing. Whatever process you follow without that
you're always in trouble (requirements, design, coding, testing, etc. all
those need good people). What I really hate about the Agile consultants, etc.
is that many say switch to Agile and the world becomes a better place. Not
with bad people it doesn't.

However, I think a lot of the Agile stuff can really help get the best out of
the good people. For the bad people I have seen it work the opposite way -
they lose the safety net of structured requirements analysis, design, etc. and
end up creating a mess.

Best part for me was the link to the anti agile manifesto:

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

------
rnernento
One if the issues I see with Agile in practice is that it draws clear lines
around individual tasks. Developers become responsible for their own
individual tasks but don't take responsibility for the project as a whole or
how that task might fit into it. For a small already effective team the
adoption of Agile really just resulted in more meetings and less cohesive end
results.

~~~
dragonwriter
> One if the issues I see with Agile in practice is that it draws clear lines
> around individual tasks.

There are no doubt methodologies that do that, and some of them are probably
sold as being "agile", but there is nothing particularly agile about doing
that and most writing son Agile (and its close relative, Lean) actually
recommend doing the exact opposite and eliminating most role distinctions
within development teams and finding ways to establish broader collective
ownership of the product as a whole (different authors differ in the specific
approaches they recommend trying in order to achieve this.)

> For a small already effective team the adoption of Agile really just
> resulted in more meetings and less cohesive end results.

That sounds like you didn't adopt Agile -- the orientation toward software
development encompassed in the Agile Manifesto -- but some externally-defined
canned process that some consultant slapped an "agile" sticker on to sell to
people who don't know what Agile is.

If your existing pattern of interactions is working effectively, "adopting
Agile" shouldn't mean much change besides something like periodic discussions
of how it is working, and what any pain points are in it, and how to tweak it
to resolve those pain points.

In fact, even if your current processes _aren 't_ working, that's what
adopting Agile should look like at first -- any bigger changes should come out
of what the team discovers in those discussions (which may then lead to
adopting, on a trial basis, particular practices that have been defined
externally that appear to be designed to address the issues that the team is
having to evaluate if they work for the team, but adopting a set of canned
externally-defined processes without reference to the specific needs of the
team _isn 't_ adopting Agile -- its something opposed to Agile that puts
process over people and interactions.)

------
sramsay
I think Agile is (was?), in the end, yet another attempt to make software
development behave like other areas of engineering -- a domain in which
processes can be trusted over people, and in which a certain set of
predictable inputs will reliably produce an assured set of outputs.

Of course, whether "other areas of engineering" are like this is another
question (I suspect that when there's a five billion dollar cost overrun on a
bridge, we have our answer about predictable processes).

But in the larger sense, I think this is the dream of every geek -- a
_process_ , a _system_ that works independently of the people involved. We're
going to keep chasing that one down for as long as our business is around.

I think Agile changed the way we all work, but it didn't fundamentally change
the nature of the endeavor, which is full of guessing, hunches,
miscommunication, dropped balls, and overreach, as well as insight, heroism,
eleventh-hour refactors, and (above all else) lessons learned through bitter
experience.

~~~
IanCal
> I think Agile is (was?), in the end, yet another attempt to make software
> development behave like other areas of engineering -- a domain in which
> processes can be trusted over people

I don't know where you got that idea from, given this vital line in the
original manifesto:

> Individuals and interactions over processes and tools

[http://agilemanifesto.org/](http://agilemanifesto.org/)

The entire point was to get past the "one size fits none" solutions and just
_build some stuff_.

~~~
sramsay
A manifesto written _after_ the first burst of agile enthusiasm (and the first
major public "failure)."

Do you really read, say, the original _Extreme Programming_ book as being in
line with that manifesto?

------
atlantic
>Now the question is: what will guide Agile through the “slope of
enlightenment”?

Ditch the Agile consultants. Let each team build its own understanding of
Agile principles, and implement Agile in its own way. Once Agile stops being
an over-hyped cash cow, it may again bring some benefits to software
development.

In other words, and as the author says, back to basics.

------
programminggeek
The thing I see every time someone decries the death of agile is that they
fail to mention or probably aren't doing retrospectives after every sprint.
Good retrospectives aren't complicated and don't take that much time, but they
are arguably the most important part of a successful agile team.

Most of the best ideas in agile come from lean manufacturing concepts and
arguably the most important part of lean manufacturing is continuous
improvement. Continuous improvement in software process comes from
retrospectives.

When teams fail to do retrospectives, they fail to learn from their mistakes
and discuss ways to improve. I don't care what your process is, if you do
retrospectives consistently and commit to take action after each
retrospective, you can make any process more awesome.

Teams that don't improve their process end up with a crappy process that
nobody likes. This is not an agile specific problem.

------
vannevar
This is a poor argument. The first three "myths" in the article are all straw-
men. First, Agile isn't a design process, it's an _implementation_ process.
How you arrive at those user stories is up to you, and nothing in Agile
proscribes using OOD, SOLID, patterns, or any other software design process
your heart desires. And please show me the Agile article that says that you
should constantly refactor working code, or that technical debt should be
accumulated freely because it can _always_ be repaid. Myth #4 might make the
basis of a good article (and has), but it hardly means the end of agile to
suggest that just blindly following agile rituals doesn't guarantee agility.

~~~
darkxanthos
Show me where in the agile manifesto ANY process is recommended:
[http://agilemanifesto.org/](http://agilemanifesto.org/)

This is the entirety of the issue. Once one refers to it as a process their
entire argument is flawed.

~~~
fennecfoxen
You click the 'twelve principles' link and go to
[http://agilemanifesto.org/principles.html](http://agilemanifesto.org/principles.html)

For instance: "At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly."

Oh hey! It's a process! Heck, it's like a meta-process, even. THE meta-
process.

~~~
darkxanthos
That appears to be the only point in that page that resembles a process. And
really it's self-reflection as a principle. But really a process is more
mechanical. The manifesto says "Hey! Reflect regularly." That is not the same
thing as saying "We must have a retrospective every 2 weeks using the force
direction exercise..."

Your calling it a "meta-process" implies to me that you also get that
distinction.

~~~
dllthomas
_' Your calling it a "meta-process" implies to me that you also get that
distinction.'_

I interpreted "meta-process" as simply a remark that the process (presuming it
is one, but that seemed to be the orientation of the author) addressed
processes.

------
darkxanthos
With any story like this there's always one bit that's understated. There's
agile as it is practiced and agile as it is described by the founders. They're
quite different.

Agile as described by the founders is so squishy it can almost never be wrong.
How so? There is no process. There is no explicit denial of waterfall process.
There's only values and stated preferences. If an agile project fails one can
always say "Why didn't you choose a better process for the people?"

Ultimately the whole point was to deliver working software and optimize for
change. That hasn't died as far as I can tell... We just achieve it in many
different ways. What could be more agile than that?

------
UK-AL
"In my personal opinion, we will have to go back to the basics: To all the
wonderful design fundamentals that were being discussed in the 90’s: the SOLID
principles of OOD, design patterns, software reuse," \- Err, Agile is based on
those principles to. Agile takes quality above all else, a task is not
finished until its finished well.

Agile has always been combined with software craftsmanship, especially XP
style engineering principles.

------
bayesianhorse
The article to me feels like the author has a high appreciation of his own
understanding of software development - and maybe even very rightly so - but
doesn't want to put this in a certain language other people developed (in this
case "agile" methods).

I don't believe technical debt can be avoided. And it seems counter to the
"debt metaphor" that you take time away from working on current demands to
save time later. There seems to be no real evidence that time spent now is
necessarily worth more time later (beyond reasonable planning or avoiding
really stupid decisions). The debt metaphor would actually mean that time now
is worth more than time later (time value of time, if you will).

Probably it depends on where the time for "avoiding technical debt" is
actually taken away from...

------
k__
My Software engineering Prof. Once wrote, those agile methods were first used
by highly skilled teams that knew what they wanted. There has never been any
evidence for them to be a silver bullet.

Big planning slows down experienced engineers, but can help the unskilled
quite well...

~~~
tbrownaw
_My Software engineering Prof. Once wrote, those agile methods were first used
by highly skilled teams that knew what they wanted. There has never been any
evidence for them to be a silver bullet._

This is the case for pretty much anything new and cool.

 _Big planning slows down experienced engineers, but can help the unskilled
quite well..._

Plans serve (at least) two purposes.

One is so that _you_ know what you're doing. This doesn't have to be formal
and can live partly inside your head. Experienced people probably do more of
this, they just do it faster and don't bother writing as much of it out
(because recalculating on-the-fly is faster and less error-prone than looking
up last week's overly-detailed predictions).

The other is so that _other people_ know what you're doing and when you'll be
done with it. For this the proper amount is whatever provides the most useful
information (for all combinations of "most" and "useful"), without taking so
much time as to cost more than it's worth.

------
MarkMc
Agile may be dead, but not for any of the reasons the author describes. The
first first two 'myths' are not something that Agile claims, and the last two
'myths' are in fact true.

> Myth 1: Good design will emerge from the implementation of user stories ...
> However, in practice the code does not have this tendency to self-organize.

 _Code_ may not self-organize, but a small team of programmers can. It is not
the implementation of simple user stories that produces good code but rather
the ability and willingness of the team to constantly refactor the code. The
main point of Agile development is that you get better quality code written
faster if you take a somewhat messy codebase and refactor it, instead of try
to come up with a great design before writing any code.

> Myth 2: It will always be possible to pay the technical debt in the future
> ... However, in practice it is not so easy to pay the technical debt.

Agile doesn't claim it's always possible to pay technical debt in future,
otherwise there would be no need to refactor code. What it does say is that
programmers have a tendency to overestimate the chance that the chunk of code
they are working on will need to be clean and flexible in future (ie. "You
Ain't Gonna Need It") and to overestimate the cost of future refactoring if it
does. A good example is copy-and-pasting: It's generally fine to copy and
paste a chunk of once or even twice - only on the second or third copy should
you start to refactor it.

> Myth 3: Constant refactoring is an effective way to produce code ...
> However, in practice refactoring is consuming an exaggerated amount of the
> efforts invested in software development

There's no question that constant refactoring takes as a significant chunk of
time in Agile, but not much more than the design phase in other workflow
processes. And in my experience it is simply the way to maximise the long-term
addition of value to the codebase. It's a bit like that old story about how
the fastest man to chop down trees spends most of his time sharpening his axe.

> Myth 4: Agility can be assured by following an Agile process ... However, in
> practice the process alone is not able to provide change-resilience

Again, this simply has not been my experience. The only time I have found
refactoring to be painful and difficult is when the codebase has had bits of
code gingerly tacked on over the years without any refactoring - and that
certainly isn't The Agile Way.

> The consequence is that some teams implement new features very fast in the
> first iterations, but at some point their work halts and they start spending
> most of their efforts in endless refactorings.

News Flash: It is ALWAYS easier and faster to write code on a greenfield
project than a large, old codebase - dumping Agile will not change that. At
the risk of sounding elitist or relying on the 'one true scotsman' argument,
maybe the author has simply not worked with people who are good at
refactoring. It certainly is a skill and many programmers don't have it.
Here's a great quote [1] written seven years ago on this point:

> "for me, a lot of the differences between the best programmers I've worked
> with and the worst are simply the quality of the abstractions when they pull
> out pieces of code to reuse. Often, even when it's clear that someone needs
> to build a piece of reusable code to call from many places, the results will
> be very different. Some people are naturally good at producing clean and
> elegant abstractions to reuse, while others' abstractions tend to leak and
> be a little hairy looking, making them harder to work with."

[1]
[http://www.reddit.com/r/programming/comments/2d2e0/theres_no...](http://www.reddit.com/r/programming/comments/2d2e0/theres_no_programmer_who_does_the_work_of_ten/c2d3zb)

~~~
claudiusd
> maybe the author has simply not worked with people who are good at
> refactoring

I agree with you 100% but this line got me thinking... shouldn't a
methodology/process in principle lower the skill level required to be
effective? I understand that Agile does to an extent, but perhaps the fact
that "refactoring" is hard means the process has shortcomings?

~~~
JoeAltmaier
That's one possible purpose to a process. Another is to increase reliability
e.g. get the same outcome every time. Like 'complete on time'. Anybody can
benefit from that, even the most senior of developers.

------
vpeters25
I though this was the quarterly "why agile sucks" post on HN but instead it
seems to list bad habits worth avoiding in effective agile teams.

If your agile consultant is promoting any of these myths you need a different
one.

