Agile Is Dead, Long Live Continuous Delivery

I totally agree ... Don't waste your time reading this article. And if you ever have the opportunity to write an article yourself, remember one simple thing - if you're going to write several hundred words of content, you should try to tell your target audience something they don't know!

There's "Agile", the buzzword that all sorts of advice-givers have capitalized on commercially, and then there's the Agile Manifesto [1]. The Agile Manifesto has merit and is a set of values, not a methodology - it would precisely agree with your advice to chiefly "use your brain". It's unfortunate that the latter has been turned into a Frankenstein's Monster of the former. [1] http://agilemanifesto.org/

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.

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!

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