
Agile Is Dead, Long Live Continuous Delivery - aechsten
http://gradle.org/blog/agile-is-dead/
======
lostcolony
I like how he tries to supplant agile with something that doesn't even attempt
to solve the same problems that agile (like waterfall before it) attempts to
solve.

Both agile and waterfall methods attempt to give you a pattern by which you
can predict when software will be delivered. That's the main business value.
The suits don't care how the devs operate, provided they can get things on
time.

Waterfall tried to do this by trying to understand the problem as fully as
possible, to liken it as much to previously solved problems, and to involve
gurus to say "that kind of problem will take X amount of time to resolve", and
thereby create milestones and delivery dates.

Agile instead said "look, we don't know enough at the start of a project to do
that. Let's instead keep track of everything we want to do. Let's try and
estimate each set of tasks (stories), individually. And then let's rank them
in priority. We can measure how good our estimates are, we can modify them, we
can generate more data and determine what we'll have at a milestone, and then
can either push back the due date, or at least recognize that we won't be able
to ship the entire feature set at that time.

Continuous delivery can be done with either one of those (it almost never is
in waterfall, but it -could- be). But by itself it offers a business nothing
for planning purposes. All it does is allow an immediacy, a "as soon as it's
done it's out in front of the users". This may or may not be a good thing to
the business, but it doesn't solve the basic issue that business people want
to know when they can expect a given set of features to be live.

~~~
voodootrucker
The trouble is that in dynamic environments, the discipline necessary to
properly practice scrum isn't really possible. It takes longer to define the
requirements than it does to code, and once coded they change mid-sprint.

The trouble with waterfall is that it tries to predict beyond the scope of a
sprint, which just isn't valid. Project estimates are asymmetrical curves
(likely poisson?) and you can't add them up and expect them to cancel out:
[http://www.sketchdeck.com/blog/why-people-are-bad-at-
estimat...](http://www.sketchdeck.com/blog/why-people-are-bad-at-estimating-
timelines/)

The problem is like recursive state estimation, except when you break it down
just to estimate and add it back up you aren't actually taking any new
measurements.

On most projects it's usually just better to estimate based on relative size
to your last project, start delivering continuously, and do a forecast of
completion (as opposed to an estimate):

[http://www.agildata.com/keep-it-lean-you-arent-ready-for-
scr...](http://www.agildata.com/keep-it-lean-you-arent-ready-for-scrum/)

(edit: spelling)

~~~
barrkel
_The trouble with waterfall is that it tries to predict beyond the scope of a
sprint, which just isn 't valid._

This assertion is nonsense. There's nothing magical about a couple of weeks
such that it forms a boundary outwith lie impossible predictions. The validity
of predictions depend entirely on the understanding of the problem domain and
the complexity of the solution space.

The single biggest benefit from agile in theory, IMO, is controlling risk by
getting the customer in front of the software sooner, so it can be iterated
based on feedback. The primary risk being controlled is building the wrong
thing. But you wouldn't develop e.g. an autonomous driving subsystem for a car
that way.

Agile (scrum, specifically) in practice is too often used simply to chop large
tasks into bite-size stories to be fed on a conveyer belt to a team of more or
less replaceable programming cogs; the sprint scope keeps blinkers on
everybody so they don't look too far in the future, they just keep munching
through stories.

And when agile is used in this way, not only can it be demoralizing, but also
extremely inefficient: a focus on user stories typically encourages building
small features that involve narrow vertical slices through the stack of an
application. That's hard to parallelize effectively - related stories will
affect the same bits of code and cause conflicts. If you can bundle a bunch of
related features together based on how they are likely to be implemented, you
can slice them up horizontally, and implement the different layers separately,
using things like APIs and data models at the boundaries. This paralellizes
quite well at the team level.

It's still not great for software design. It's still a very blinkered
approach; you're not going to design an application-specific framework that
makes implementing features easy. It doesn't allow any space for experienced
developers who have foresight, and relies on refactoring to create reusable
domain-specific abstractions. But refactoring isn't a user story, and a team
munching on stories isn't in a good position to think holistically about a
problem.

~~~
blowski
If you've got a bunch of good, productive developers, you've got to work
really hard to get anything but good software out of them. They will probably
self-organise into an effective team, whatever the methodology.

On the other hand, if you have a bunch of inexperienced, mediocre developers
(myself included) then "bite-size stories being fed on a conveyer belt" is
probably a good way to get productivity out of them. It's certainly a lot
better than "you have 3 months to build this enormous system based on this 1
paragraph brief" which is pretty common.

~~~
barrkel
You'll get a blob that gets harder and harder to modify over time. For a
throwaway system and / or with piles of money, it may work until the system
needs replacing.

Different people working on similar vertical slices through the system leads
to slightly different parallel implementations and probably some duplication
of helper logic. Refactoring won't get scheduled and it'll become technical
debt in the way all duplicated logic is: not a big deal to start with, but an
increasing source of bugs and features fixed / implemented in one place but
not another.

Inexperienced developers won't be disciplined in keeping their abstractions
separate; they tend to intermingle their abstractions so that the boundary is
fuzzy. Specifically, they lack layering discipline. Instead of libA using libB
which uses libC, they'll pass bits of libA into libB and return bits of libC.
When implementing a complex algorithm that joins libA to libB, they'll write
code that zips the two together within its convolutions, rather than creating
adapters for libA and libB so that the algorithm follows naturally. And
they'll model the domain, but nothing much more abstract, and write convoluted
procedural algorithms in VerbingClasses (new ThingDoer(x).doThing(y)),
possibly with interfaces for mockability.

And to be frank, many line of business applications can cope with this. The
developers are cheaper and easier to find, and IT was always a cost centre
anyway. It's no way to live if you love code, though.

~~~
blowski
Of course. If we lived in a world where good, productive, experienced
developers were cheap and plentiful, we could do things very differently. As
it is, it can be more efficient to pay cheap developers to continually patch
(or even rebuild) big balls of mud than pay expensive developers to build it
properly in the first place.

And I'm not going to complain, because I benefit from the current system.

------
morgante
I stopped reading at "Agile had a great run in it’s youth by taking on some
obviously bad practices such as 'Waterfall' software development."

Nothing about waterfall is obviously bad. It's how most engineering projects
are done. Heck, it's how most projects generally in the world are done.

There's a reason it took a long time to move away from waterfall. It solves
obvious problems and meshes with how the rest of corporations typically
operate. In fact, with software delivery methods which were dominant back
then, agile probably would have completely failed.

\---

In the end, I ended up reading the full piece. One doesn't get much more
oblivious and buzzwordy than this:

> We are now more squarely in the age of Microservices, Mobile first,
> Polyglot, post-Java JVM languages, GitHub, Docker and the emergence of a
> world being eaten by Software.

How is this piece on the top of Hacker News? This piece reads like it was
written by a marketing consultant with no idea what these terms actually mean
or how software is actually built.

~~~
emitstop
Yeah and I like how he goes in on 'Agile Gurus' and then at the end of the
article plugs his continuous delivery conference like it isn't the exact same
thing in a different hat.

------
coldtea
"Continuous Delivery", huh?

Yeah, let's replace one consulting fad (the 4 or 5th I've seen in my career, I
entered when "Waterfall" was still in vogue, then XP, then Agile, some
variations of each too) with another.

How about this methodology: [http://programming-
motherfucker.com/](http://programming-motherfucker.com/)

~~~
chrisseaton
People tell me that waterfall was never really a thing, and it was only ever a
name for how things should not be done and that nobody ever actually advocated
it.

Is this not true? I'm too young to remember what came before agile.

~~~
andrewbinstock
Pure waterfall as it's depicted by Agile consultants was never a thing. Think
about it, how could you possibly code an entire app and only then debug it?

However, there was a waterfall-like process that was widely used. After
getting the reqs and design in place, you started coding and you mostly coded.
You would compile as you went along and made sure that your code worked on the
handful of tests you put together as you went along. When the app was mostly
coded, you then started more serious testing: writing more elaborate tests and
verifying functionality. This step often highlighted buried errors that you
then spent time debugging, writing additional tests, and so on.

So, the biggest innovation in Agile was the latter's orientation towards
developer testing concurrently with coding. Which, of course, has had many
other ramifications.

While the old way of doing things might sound klunky by today's standards,
when done right it actually worked better than its reputation. Because devs
hated spending hours in the debugger, they tended to code very carefully. The
concept of "let's code this and run it through some tests to validate it" was
unknown. Rather you coded so that you were pretty much sure that what you were
writing worked properly if it compiled without error.

~~~
gnaritas
> Pure waterfall as it's depicted by Agile consultants was never a thing.

Yes it was.

> Think about it, how could you possibly code an entire app and only then
> debug it?

Which is why programmers hate waterfall so much, but you're absolutely wrong
to think this isn't exactly what was being attempted. Time and time again,
management in an attempt to cut the cost of programming time, thought the way
to do it was to first build specification for everything and try and prototype
the entire app up front, storyboard every screen, build out mountains of specs
because naturally they think that's how you build things, with detailed
blueprints so all the decisions have already been made. They couldn't be more
wrong, but it's certainly the most natural way to think if you aren't a
programmer and don't know better.

> So, the biggest innovation in Agile was the latter's orientation towards
> developer testing concurrently with coding. Which, of course, has had many
> other ramifications.

Agile in general had nothing to do with testing, the big change in agile was
removing the big design up front, the specs and meetings and months spent
planning something before being developed. Some agile methods like extreme
programming certainly had testing as a big part of their process, but what
differentiated agile from waterfall was introducing iterative programming
where work was done in short week or two cycles and then delivered whereas
waterfall wastes enormous time trying to nail down details that simply ended
up being wrong come programming time.

tldr; agile is not about testing, it's about iterative development in short
cycles with little planning and always has been and that's what made it
different from waterfall; no "Big Design Up Front".

~~~
ternaryoperator
"Pure waterfall as it's depitected by Agile consultants was never a thing."

This is correct.

The first paper to describe a stepwise model was by Royce in 1970 [1]. The
model he is describing is hypothetical and does not use the term Waterfall.

The first use of the word "waterfall" (including the quotation marks) is from
1976 [2] and specifically refers to [1], the hypothetical model. In [2], the
writers specifically state that "so few" projects fit this scheme.

If you were programming in the 80s and early 90s, you would know that no one
in programming ever referred to a "waterfall" model.

Even Kent Beck's seminal book on XP, written in 2000, describes many failures
of software development in those days, but he does not once use the word
Waterfall.

So, in summary: the paper that supposedly describes it describes a
hypothetical system; the paper that first uses the term mentions how little
the model is used; the term wasn't used by people during the era it was
supposedly most popular; and the folks who initiated the new generation of
software dev don't refer to the model.

I think it's safe to say that it was not a thing. Or, to be more accurate, if
it was a thing, it was never the thing it became until the Agile consultants
used is as a strawman.

[1]
[http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...](http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf)

[2] [https://goo.gl/eYLBN7](https://goo.gl/eYLBN7)

~~~
gnaritas
You're wrong. Look at the responses you're getting, many of us were there in
the 90's and if you think waterfall wasn't the dominant method of developing
then you just don't know what was going on back then. It doesn't matter if
they called it "waterfall" or not, it matters that it's simply what they were
doing. Massive requirements gathering and spec writing with development being
considered like construction of a blueprint at the end of a months/years long
cycle. That's how development was done before agile came around.

Waterfall still isn't dead and will never die because it's how people think by
default, plan it all out, then build it. That's how buildings are made and
thus it becomes the default methodology of all new managers who don't know
what they're doing.

~~~
coldtea
Parent just took a "conspiracy theory" thing that's popular around Waterfall
and run off with it.

------
dronacharya
Here's a quote from the first paragraph of this page:
[http://agilemanifesto.org/principles.html](http://agilemanifesto.org/principles.html)

"Our highest priority is to satisfy the customer through early and _continuous
delivery_ of valuable software." (Emphasis mine)

Continuous delivery has been an integral part of agile methods since the very
beginning.

------
jheriko
buzzword filled click-bait. :/

just use your brain. agile is only a problem when people follow it religiously
instead of intelligently imo.

its just one tool in the box, not the ultimate methodology.

~~~
scolfax
Agreed.

But feel compelled to add: Agile is only a problem when teams pretend to
follow it but actually don't.

~~~
p4wnc6
When everyone misuses a tool, it's the tool's fault. And _everybody_ misuses
Agile.

~~~
jheriko
some over quoted thing about bad workmen comes to mind...

i prefer to think that a master craftsman is one who can take any tools and
materials and use them to produce good work... if not exceptional.

~~~
hinkley
That is not what "a poor craftsman" means.

Doing awesome things with primitive tools is a parlor trick. Grandstanding.

The craftsman blames themself for using the wrong tool for the job, not the
tool.

------
terryf
Clearly the article is just a thinly veiled advertisement, but leaving that
aside:

Apparently the author hasn't really read the agile manifesto, because nowhere
does it talk about scrum or sprints or xp or any of those things.

The agile manifesto is essentially a few sentences, that very eloquently say

"Don't be a dick and understand that the product people or customers don't
really know what it's supposed to do either."

Much like the bible took Jesus's essential point "Don't be a dick." and
wrapped a terrible mess of a system around it, the various agile methodologies
have done the same, but the essential point of the manifesto is as relevant
today as it was when it was invented.

(Note: I'm not actually religious, the Jesus thing was just a comparison)

------
xirdstl
This blog post is just an advertisement for the Gradle Summit.

~~~
vorg
If you click on (gradle.org) at the end of the title above, you'll see a long
list of pages submitted to Hacker News from that website.

------
hoodoof
Sounds like he is heralding a new age when people just go to work and.... do
programming.

[http://programming-motherfucker.com/](http://programming-motherfucker.com/)

Customer: errr.. what methodology are you following?

Developer: none of that agile garbage I can tell you...toxic stuff. I am
programming.

------
emblem21
Projects die all the time. Even languages can (mostly) die. The death of a
project is a valid part of a project lifecycle and knowing how it dies can
affect how you deal with previous project phases.

Agile never assumes project death is a reality. It philosophically implies
that you can always measure and iterate your way to the next phase... but
that's just not true. No one measures and iterates their way to a dead state
on purpose and yet, projects end up there all the time.

So how are the projects getting there and what is Agile doing about it? And
don't give me the Agile vs. "Agile" argument. Assume a flawless execution of
agile principles with completely accurate measurements and successful
iterations took place when answering that question.

To me, agile just assumes infalsifiability because it refuses to acknowledge,
let alone, prepare for project death. And worse, according you agile, you can
even measure and iterate your way out of the grave.

The operation of a projects has more in common with biology than immortality.
Treating projects like immortals flies in the face of the reality of project
lifecycles and it brings very bad mental states to problem solving. It makes
far more sense to treat a project in lifecycle phases (birth, child, youth,
adult, mature, elderly, dead) than assuming a singular monolithic philosophy
that completely ignores the arc of a project.

A: "The code base is too unwieldy, no one understands it any more"

B: "Oh, just measure and iterate"

A: "But that just creates more unwieldy code!"

Agile makes sense as a subphase of a project lifecycle for when that lifecycle
is spinning its wheels in the mud, not as a end-all-be-all philosophy.

TL;DR: Agile should used if a project stalls, not as a guiding philosophy.

------
strictfp
Continious delivery _is_ Agile.

In fact, regular deliveries are by many considered the single most important
indicator of a working Agile process.

~~~
kensign
Exactly, every 2 weeks, sometimes less, we consistently release what has been
accomplished in a sprint. This "blogger" is talking out of his ass. Like
always, declarations like this stir the anti-agile rage pot. It's getting more
and more laughable as the years go on.

------
moonshinefe
The problem with these buzz words is it seems most people can't seem to agree
on what they mean. This author seems to think continuous delivery replaces
agile, case in point.

It'd be nice if people could just layout concrete development / release plans
and not assume everyone has the same interpretation for the buzz word that
happens to be in vogue for a particular management team.

Oh, you didn't read all those development methodology books?!

I'd sort of like to speak plainly and get programming done, personally.

------
ebbv
So to summarize this article:

\- Agile is Dead because people abused it, so we should move on from the term.
\- Instead use the term Continuous Delivery. By the way this term doesn't mean
anything, use whatever system you want. \- Lots of buzzwords.

------
qaq
We could create a template for such articles {Buzzword} is dead because
{random text {sprinkle buzzwords}} {Plug some commercial thing}

~~~
qaq
Which summarizes half the biz model HubSpot is advocating :)

------
rbanffy
I see it more as death by ubiquity. When the last laptop is sold, we'll
proclaim the computer is dead, but we'll do so from our phones, tablets,
headsets and whatever we use to tap into vast AI's that help us navigate the
unfathomable complexity and depth of an ocean of information.

We will proclaim agile is dead without realising we constantly adapt our code
to changing needs of our users and their representatives who are very deeply
involved in the whole process and who give us feedback as we constantly
release new functionality.

------
ralmidani
I can't wait to hear someone declare "programming methodologies are dead. Long
live programming."

~~~
ktRolster
This might match: [http://programming-motherfucker.com/](http://programming-
motherfucker.com/)

------
usloth
If Agile is dead, why is there a new article about Agile on HN everyday. I
think Agile is dying, not dead.

~~~
enjo
I see no indication that agile is dying. The consultant speak cult that
developed around it is. The hugely processed SCRUM version of it seems to be.
Yet the fundamental idea behind Agile (in the manifesto) seems to be as
relevant as ever:

>Individuals and interactions over processes and tools

>Working software over comprehensive documentation

>Customer collaboration over contract negotiation

>Responding to change over following a plan

The process we've designed and use daily at Gridium most definitely adheres to
those principles. We've tested and abandoned the idea of "sprints" and weekly
estimation cycles. We have no idea what our "velocity" is.

Yet we collaborate with customers nearly constantly. We are highly responsive
to changes in the business. We integrate continuously. We deploy very often.
All ideas that I think where present when we all fell in love with the idea of
"agile".

* Edit: Shame on me for not reading the article, because I basically summarized it :) Heap your downvotes on me HN!

~~~
maxxxxx
Yep. If people checked their actions against the agile manifesto they would
immediately see that most scrum teams violate "Individuals and interactions
over processes and tools" and "Responding to change over following a plan". A
lot of scrum teams I see are fully process and tool oriented and have no
ability to respond to change. I hate when I hear "Yes you are right but we
can't make changes because the sprint would not finish".

I also have given up on fixed sprints for my (not anymore) scrum team. We have
a prioritized backlog and whatever is next gets done. More like Kanban. As
long as people behave like adults and do their work efficiently it works
pretty well. We still have a weekly velocity and that number is surprisingly
reliable.

~~~
geebee
The daily standup ("scrum") did make some sense in the context of agile
development. The idea is that you embrace the unpredictability of software and
respond to change. So you take on a task, but you accept that the task is
likely to not go as you expected. You may need to change direction. You may
need to take a different approach. Or you may need 10 weeks instead of 1, and
even that is getting fuzzy… under these circumstances, it can be useful to
remain in frequent contact with the development team and business/end users
users.

But as you pointed out, daily scrums can essentially devolve into what is
essentially a policing of developers to make sure they are staying the course
and are reminded daily of their deadlines.

It's actually just an unusually unfriendly version of waterfall. Why? Cause at
least in waterfall, the business users are forced into something unfair and
impossible as well. It's impossible for developers to accurately estimate
completion dates, but it's also impossible for business units to accurately
and fully spec out a software application. "You didn't meet your estimate"...
"Yeah, well, you changed your mind".

It's a nasty business, but there you go. Best to avoid the entire thing and
work on projects that are very high value but aren't deadline dependent, where
the value of a developer is measured by working software at reasonable
intervals rather than daily discussions of sprints, stories, and deadlines.

Actually, in some ways, that sounds more like what agile is supposed to be
than all this scrum/velocity/stories stuff that isn't in the manifesto in the
first place.

------
mschuster91
> If you’re unable to keep pace with the rate of change of the open source
> components you depend on, you will be frozen and stuck and unable to ship
> software properly, a state we at Gradle call “Build Hell”.

Or do it like anyone who wants to build a business that lasts longer than 2
years: use stable, battle-proven software only and don't run after every
hipster trend (remember EmberJS and friends). Before you use any software
component, evaluate its support lifecycles and how well it is being maintained
- especially with the trend of "modularization", where stuff like a string pad
function is a separate module, every additional dependency you pull is a
potential security issue.

Oh, and don't make the cardinal error of putting your node_modules/vendor
folders into .gitignore. THAT is build hell once someone unpublishes a popular
module...

------
xirdstl
Out with the old buzzwords, in with the new.

~~~
jonnathanson
"Meet the new boss, same as the old boss."

\-- The Who

------
Zigurd
Agile is "dead" because it isn't practiced. Where and when it is implemented,
it's just fine. But 90%+ of "agile" is actually a sloppy, lazy, underspec'ed
waterfall process hoping to achieve results in a stealth fixed-bid model,
tracked on a kanban board.

The other side of the coin is that defending agile falls into the No True
Scotsman trap too easily: Since people don't practice agile, failed projects
aren't agile. Well, of course.

The real problem is how do you get the people who _could_ be doing agile to be
motivated to access the benefits of agile, and how do you get the borderline
cases to acknowledge their limitations and address them.

------
ktRolster
Has anyone ever worked on an 'agile' team that wasn't based around scrum or
XP? I'd be interested in hearing your experiences.

~~~
nessus42
Yes, we use Kanban where I work. We've been doing "continuous delivery" and
"DevOps" for years.

It's not bad, but I still don't really like scrums.

~~~
joeblau
What's "DevOps"?

~~~
nessus42
It's when you do software development for services that are constantly
changing and need to be up all the time, and you are not only responsible for
the development, but also for the services being up all the time.

------
ricardobeat
"Agile" is not selling tickets anymore, let's come up with a new buzzword!

~~~
digi_owl
Time to print some new bingo boards?

------
vlehto
I used to study construction engineering and now I work in construction.
"Waterfall" is still in use and going strong. Applying that directly to coding
seems bit stupid.

I then swithed major to mechanical engineering, and there "toyota production
system" is the thing. Agile and lean are just taking the underlying idea bit
further. The original idea is to eliminate intermediate storages. This happens
by making every production cell to order shit from previous production cells
via kanban card. Previous idea was to just optimize volumes of every cell
while giving zero fucks who, when and why the product was needed. But even
inside the realm of mechanical engineering this sometimes is plain stupid. For
example the workflow of large castings doesn't follow rythm of manufacturing
cells. It follows the rythm of curing molds, heating metal and waiting the
metal to cool down. What is "Agile" in software seems to follow TPS somewhat.
You do one unit of work, you cash that in and start on second one. Id guess
it's just coincidence that short compiling times and intermediate storage
elimination happened during same timeframe and that resulted one term for both
"agile".

I have very limited experience on coding, but neither of the previous seem to
fix any underlying hard problems in coding. When I code, I struggle with
interfaces, specs, debugging and data flow. The only thing that comes close to
coding is design of mechanical parts. But that has lot less degrees of
freedom. And there seems to be pretty much zero management fads applied to
mechanical design anymore. The only thing everybody is saying is that "try to
keep open mind in the beginning of process. And spend some serious time
defining your problem, because that's what affects total costs most". The rest
is just going by gut feeling.

We have ISO and ASME, but still interfaces are some of the most tricky
subjects around in mechanical design. I'd expect the next meaningfull paradigm
for coding to focus on interface design, as it's the one that requires
communication between human beings. And it sets limits to what individual
coders can achieve.

"Never stand between craftsman and his professional pride" Quote by Kalevi
Aaltonen, but I guess he got it from somewhere.

------
geodel
I don't know what to think about it. The gradle.org website screams consulting
with its slickness and free user guides/books etc. It does not look like
honest, no-nonsense build software.

The source code is about 6000 Java files + 3200 groovy files besides many
others. To me it appears excessive and over designed software. I will be very
reluctant to use a build software which needs 300+ pages user guide.

TBH it is entirely possible that I just do not work on such complex software
projects which needs tools like these.

~~~
vorg
After James Strachan was knifed 2 years after he created Apache Groovy, that
ecosystem has been all about consulting and conferences. Software such as
Grails and Gradle is shoved down people's throats with promises of managing
complexity and giving users choices, but in reality these tools add complexity
and the documentation obscures. Then the sales calls start touting conferences
and paid services to manage it all.

------
tempodox
I'm sure one can always find the next buzzword to sell seminars about.

------
WWKong
There will be many comments pointing, "agile works great when implements the
right way". While that might be true I'm willing to bet good money that agile
has turned out to be really bad for 90%+ of the teams. I tried hard to save my
org from agile and failed. Everything crashed and burned soon after.

~~~
mywittyname
This is my experience too. Companies bring in agile consultants to tell them
how to release software better. But things never improve, and in two years,
they do it over again (but with a different buzzword).

If your company has trouble developing software, the problem has nothing to do
with development processes. The problem is always management.

------
daemin
With all this talk of Agile, continuous delivery, Waterfall etc, it reminds me
of a Software Engineering course I did at University. Specifically one of the
methodologies mentioned which was a Spiral model. The gist was that instead of
having one monolithic Waterfall process, you would still do the steps in
waterfall, but you would release more often and have smaller releases. So that
after a few iterations you would spiral in on the desired solution.

Upon reflection this seems like a proto-agile methodology, and because it
doesn't have its own set of buzzwords and extra processes it seems like it
could be a good reactionary (as a reaction against full Agile) methodology to
use.

------
smrtinsert
Is it continuous because the build is taking forever and never seems to
finish?

------
andrew_wc_brown
X is Dead! Long Live Y! Until Replaced by Z.

------
mml
Agile is like <pick your religion>. Widely professed, rarely practiced.

------
jcrites
The author mentions the Agile Manifesto. It's worth a read, and the concepts
it focuses on are somewhat different than the impression that you'd get by
reading about Agile in popular blog posts or websites:
[http://agilemanifesto.org/](http://agilemanifesto.org/)

    
    
      Manifesto for Agile Software Development
    
      We are uncovering better ways of developing
      software by doing it and helping others do it.
      Through this work we have come to value:
    
      Individuals and interactions over processes and tools
      Working software over comprehensive documentation
      Customer collaboration over contract negotiation
      Responding to change over following a plan
    
      That is, while there is value in the items on
      the right, we value the items on the left more.
    

That's the gist of it: _being Agile means valuing the things on the left
more_. It is a set of values, not a methodology.

I think this manifesto is wise. Like Zen koans, contemplating and discussing
it provides an understanding about what Agile is. Fortunately it's not
cryptic, although the meaning behind the statements might become clearer with
consideration and experience. "Individuals and interactions" is saying, focus
on getting people together and talking and working things out, not following a
predefined process or using complex tracking tools. "Customer collaboration
over contract negotiation" is written, I assume, in the context of contract
work, but it applies generally to the relationship between the software team
and stakeholders: collaborate with your stakeholder directly, rather than
trying to negotiate some kind of specification (contract) up front. The Twelve
Principles of Agile Software are also worth a read:
[http://agilemanifesto.org/principles.html](http://agilemanifesto.org/principles.html)

These principles are what Agile is about -- not some particular methodology.
Indeed, blindly following a methodology like Scrum would violate the Agile
Manifesto ("individuals and interactions over process"). One of the things
that I like about the Agile Manifesto and Principles is that they're not
prescribing a particular method; they are instead providing some principles to
consider while thinking about a situation. I've always liked Amazon's
Leadership Principles for the same reason:
[https://www.amazon.jobs/principles](https://www.amazon.jobs/principles) \-
insight comes from thinking about what it means to embody a principle in a
given situation; or what it means to value one principle over another, in what
situations, and why. It's not prescriptive nor a method, but it's a starting
point for discussion, and a way of talking about what we value as individuals,
a team, or a company.

~~~
danmaz74
> "Customer collaboration over contract negotiation" is written, I assume, in
> the context of contract work

This should be about contracts between software development firms and their
customers, where the development firm gives a quote to complete a project
based on very detailed and legally binding specifications - which is a big
problem because you can't know every detail before the project even starts.
Hence a big part of the "Agile" philosophy.

------
dimino
This declares Agile dead without explaining specifically _why_. From what I
gather, Agile is "dead" because no one actually does Agile, and only takes the
"grab bag" of Agile terms without going fully Agile.

If no one's doing Agile, how could it be dead, since it was never alive? Maybe
we should start trying to actually "do" Agile, to see if it might work, since
no one's ever tried it yet, according to this blog.

------
fmueller
We really need a bullshit register for this kind of people. They should not be
able to get away unpunished for releasing something they already know is
bullshit.

------
meganvito
I think what features this article is exactly what we see the one facet of
agileness of its practitioner. The distortion of science and engineering
methodology and practice. Before you do a big thing, you have to prove a bunch
of small things work as the foundation. Any increment will not be linearly
scalable. Finally, what you claim should be strengthened by your data, charts,
plots that are verifiable by others.

------
jldugger
It's funny. Our devops team is in the midsts of a long migration from cfengine
to Chef, and I recently started managing the project more like agile, with
sprints and task planning meetings and so on.

Sure, for our clients and internal developers, devops makes CI happen. But as
far as the devops themselves are concerned, Agile hasn't gone anywhere.

------
joesmo
Waterfall is still the right choice for many products. The fact that the
author can't even acknowledge that shows how little he understands about
software development. The whole article is mainly a bunch of garbage from one
narrow minded point of view with an obnoxious title.

------
cha-cho
Not hyperlinking to the Agile Manifesto in the second paragraph? Man that's
cold.

------
tomc1985
Not sure if I agree with his post, but to hell with the gurus! It's a
mentality we need to move away from, and it is nauseating the way people drool
over so-called 'gurus'. Software is not religion... it's just software

~~~
coldtea
Unfortunately it sells, and idiotic managers love it because it gives them a
ready-made recipe, instead of having them come up with something that works
for their product and their team.

------
jedicoffee
This is just an advert. Can we please stop supporting all of these "XYZ is
Dead" articles with no real solutions provided and an obvious unlying
financial agenda.

------
hyperpape
"We are now more squarely in the age of Microservices, Mobile first, Polyglot,
post-Java JVM languages, GitHub, Docker and the emergence of a world being
eaten by Software."

 _sigh_

I can see how Docker is relevant, Microservices are arguably relevant, maybe
even GitHub, but that still leaves 4 out of 7 items that have nothing to do
with continuous delivery.

------
dmtroyer
Am I the only one that thinks this 3 column layout is atrocious?

------
UK-AL
Continuous delivery is basically another form of Agile

------
triplesec
"So to eulogize Agile absolutely does not mean to go back to Waterfall, by no
means."

I think the author is confusing eulogize for euthanize, which amuses me.

~~~
mikojava
naw I meant eulogize.

~~~
triplesec
then my parser is broken because I coudn't figure out what you meant

