Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agile Is Dead, Long Live Continuous Delivery

gradle.org

Post reply on HN
Print view View original

31–40 of 157 posts

Re: Agile Is Dead, Long Live Continuous Delivery

#31

Post by jheriko »

jcrites wrote: post #23
jheriko wrote: post #6

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.

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 hate to disagree since you support me, but thats not true.

The agile manifesto has plenty of problems that should be obvious with some thinking. Some of the statements are outright ludicrous and naive as much as others are valuable insights (but even then, only if you haven't thought about the problem very much and tried to approach it in reality).

I shipped software very quickly before learning much about agile at all... I ship it even faster afterwards, but not because I agree with it all... in fact I am convinced I am better off for ignoring the more harmful aspects and selectively choosing the ones that have a measurable benefit.

Re: Agile Is Dead, Long Live Continuous Delivery

#32

Post by danmaz74 »

jcrites wrote: post #13

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/ 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 a…

> "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.

Re: Agile Is Dead, Long Live Continuous Delivery

#34

Post by maxxxxx »

enjo wrote: post #27
usloth wrote: post #2

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

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 ov…

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.

Re: Agile Is Dead, Long Live Continuous Delivery

#38

Post by voodootrucker »

lostcolony wrote: post #25

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 t…

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):

http://www.agildata.com/keep-it-lean-you-arent-ready-for-scr...

(edit: spelling)

Re: Agile Is Dead, Long Live Continuous Delivery

#39

Post by [deleted] »

lostcolony wrote: post #25

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 t…

[deleted]

Re: Agile Is Dead, Long Live Continuous Delivery

#40

Post by 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.
Post reply on HN