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.
That's one of the most level-headed and succinct description of the differences between Waterfall and Agile I have read.
I would also add that, in my completely personal and anecdotal experience, they are not one-fits-all methods: in general I find Agile much more suited to developing a "product", while Waterfall makes more sense when the aim is to deliver a "project".
My takeaway from the post is that he wants to replace Agile (clause 1: "individuals and interactions over processes and tools") with an ill-defined process (CD) and a big old pile of tools.
Call me an agile zealot fanboy or whatever, but that doesn't feel to me like progress (and, inter alia, more or less the opposite of what Dave T was complaining about in his own agile is dead thing).
I'm not a management guru, so I might be off-base but Agile isn't about sprinting tasks. Tasks, broken up enough, are much smaller than a sprint. It's about having a deliverable at a certain short term goal post. You cut corners and smash half finished features together to reach that goal so that you have a product you can pivot around (the word "pivot" always makes me throw up a little - maybe... reassess the direction of the project?). With test driven development and continual integration tools you constantly have a deliverable, so there is no longer any reason to sprint. You can "pivot" or whatever at any point in time
The real question is test driven development / continual-integration worth doing? CI isn't too controversial, but for TDD there is no clear answer and it really depends on the domain and what language you work in etc. etc.
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...
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):
Agile isn't about predictability so much as it is about 1: ensuring productive work is always going on; 2: ensuring the thing that ships is what the client wants; and 3: ensuring that something functional will actually ship.
Agile grew as a bulwark against the bad old ways of the "enterprise" trenches that led to the original "software crisis". There was a time when big software projects would not deliver, at all, as often as they would succeed. And even when they succeeded they often delivered the wrong thing. Daily builds, continuous integration, using the software itself as the source of truth (instead of elaborately negotiated specs), and focusing on iteration, these are how you can extract productivity from any team, and how you can keep on target and deliver something of value. It's not necessarily the best way, but it's one reasonably reliable way to get stuff done.
>>> 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.
Good waterfall project managers do that too. You can't bend reality to fit a gantt chart.
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.
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.
> We are now more squarely in the age of Microservices, Mobile first, Polyglot, post-Java JVM languages
Gradle provides only one language, i.e. Apache Groovy on the JVM, for specifying build configuration info. Before talking about "Polyglot, post-Java JVM languages", perhaps Gradleware needs to eat its own dogfood and provide an API so users can write their build configs in Jython or JRuby if they want. Be polyglot before preaching it.
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.
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.
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 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!
Well it's working, it's on top of HN. The problem is the people clicking in the end. I didn't, cause I know with a title like that this gona be some cheap clickbait.
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)
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.
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.
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.
- 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.
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.
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!
A better analogy, is that some of the more advanced examples have "sublimed" as in Iain M. Bank's "Culture" series.
I was just having this thought last night. "eXtreme Programming" and Scrum seem to either exist in a clunky bureaucratic mutant form or have evolved into companies that use CI and prioritize really good communication. (Yes, people in the late 90's and early 00's did sometimes write it like that.)
> 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...
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.
[+] [-] lostcolony|9 years ago|reply
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.
[+] [-] Kurtz79|9 years ago|reply
I would also add that, in my completely personal and anecdotal experience, they are not one-fits-all methods: in general I find Agile much more suited to developing a "product", while Waterfall makes more sense when the aim is to deliver a "project".
[+] [-] tragic|9 years ago|reply
Call me an agile zealot fanboy or whatever, but that doesn't feel to me like progress (and, inter alia, more or less the opposite of what Dave T was complaining about in his own agile is dead thing).
[+] [-] optforfon|9 years ago|reply
The real question is test driven development / continual-integration worth doing? CI isn't too controversial, but for TDD there is no clear answer and it really depends on the domain and what language you work in etc. etc.
[+] [-] voodootrucker|9 years ago|reply
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...
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...
(edit: spelling)
[+] [-] InclinedPlane|9 years ago|reply
Agile grew as a bulwark against the bad old ways of the "enterprise" trenches that led to the original "software crisis". There was a time when big software projects would not deliver, at all, as often as they would succeed. And even when they succeeded they often delivered the wrong thing. Daily builds, continuous integration, using the software itself as the source of truth (instead of elaborately negotiated specs), and focusing on iteration, these are how you can extract productivity from any team, and how you can keep on target and deliver something of value. It's not necessarily the best way, but it's one reasonably reliable way to get stuff done.
[+] [-] gadders|9 years ago|reply
Good waterfall project managers do that too. You can't bend reality to fit a gantt chart.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] morgante|9 years ago|reply
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|9 years ago|reply
[+] [-] vorg|9 years ago|reply
Gradle provides only one language, i.e. Apache Groovy on the JVM, for specifying build configuration info. Before talking about "Polyglot, post-Java JVM languages", perhaps Gradleware needs to eat its own dogfood and provide an API so users can write their build configs in Jython or JRuby if they want. Be polyglot before preaching it.
[+] [-] wmonk|9 years ago|reply
[+] [-] fuck_google|9 years ago|reply
[deleted]
[+] [-] coldtea|9 years ago|reply
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/
[+] [-] lsc|9 years ago|reply
[+] [-] chrisseaton|9 years ago|reply
Is this not true? I'm too young to remember what came before agile.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] amptorn|9 years ago|reply
[+] [-] dronacharya|9 years ago|reply
"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|9 years ago|reply
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.
[+] [-] jcrites|9 years ago|reply
[+] [-] smoyer|9 years ago|reply
[+] [-] spriggan3|9 years ago|reply
[+] [-] scolfax|9 years ago|reply
But feel compelled to add: Agile is only a problem when teams pretend to follow it but actually don't.
[+] [-] aivosha|9 years ago|reply
[+] [-] terryf|9 years ago|reply
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|9 years ago|reply
[+] [-] vorg|9 years ago|reply
[+] [-] hoodoof|9 years ago|reply
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|9 years ago|reply
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|9 years ago|reply
In fact, regular deliveries are by many considered the single most important indicator of a working Agile process.
[+] [-] kensign|9 years ago|reply
[+] [-] moonshinefe|9 years ago|reply
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|9 years ago|reply
- 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|9 years ago|reply
[+] [-] rbanffy|9 years ago|reply
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|9 years ago|reply
[+] [-] usloth|9 years ago|reply
[+] [-] enjo|9 years ago|reply
>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!
[+] [-] ludamad|9 years ago|reply
[+] [-] TheOtherHobbes|9 years ago|reply
[+] [-] goalieca|9 years ago|reply
[+] [-] stcredzero|9 years ago|reply
I was just having this thought last night. "eXtreme Programming" and Scrum seem to either exist in a clunky bureaucratic mutant form or have evolved into companies that use CI and prioritize really good communication. (Yes, people in the late 90's and early 00's did sometimes write it like that.)
[+] [-] tempodox|9 years ago|reply
[+] [-] striking|9 years ago|reply
[+] [-] mschuster91|9 years ago|reply
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|9 years ago|reply
[+] [-] Zigurd|9 years ago|reply
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|9 years ago|reply