Live data from Hacker News

Agile Is Dead, Long Live Continuous Delivery

gradle.org

151–157 of 157 posts

Re: Agile Is Dead, Long Live Continuous Delivery

#151

Earlier quoted context omitted.

I'm an XP fan, but I'm always wary of saying "they didn't do real agile". It can descend into "No True Agile" pretty quickly, with a dash of victim-blaming. Agile is actually hard to get to grips with. It requires lots of discipline. So did the pre-agile methods that worked best. And it gets half-done for the same reason that the pre-agile methods got half-done. It's hard. Hard to do, hard to learn, tempting to stop.

Perhaps, but one problem often seen in large orgs (I've been there personally twice, and heard many more stories from close colleagues) is that they adopt the agile methodology (sprints, stories, etc), without adopting the culture shift (shit does not get added into the middle of a sprint, ever) necessary to make it work. Agile process without agile culture objectively isn't True Agile. It's worse than everything it…

I disagree that Scrum is the whole of agile, so the concept of "sprints" doesn't exist for me. If the product manager wants to rearrange stories, that is his or her business. My business is advising on the relative complexity of stories and then undertaking to deliver the next story in the backlog. The roles are well-defined, after which, we talk to each other like we're adults trying to achieve the best outcome for everyone.

Putting aside that particular nitpick, it's easy to cargo-cult the practices. I sometimes use the analogy of the introduction of lean manufacturing in the US. At first what was introduced were the tools: boards, line-stoppages etc. But tools are just tools, by themselves they're not enough.

The uncomfortable, expensive and difficult truth in our industry is that people, process and tooling are not substitutable. You need the best of all three that you can get.

Re: Agile Is Dead, Long Live Continuous Delivery

#153

Earlier quoted context omitted.

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

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

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

Re: Agile Is Dead, Long Live Continuous Delivery

#154

Earlier quoted context omitted.

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

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

Saying that the term was never used isn't really refuting the point. It doesn't matter whether you coded back in those days. Anyone who looks at (or used) the software being produced back then can see that continuous software delivery wasn't really the norm, probably due at least in part to technical limitations. I'm thinking about your average Microsoft product, but there are plenty of examples even today of poorly-designed waterfall projects (e.g., healthcare.gov for Obamacare).

Re: Agile Is Dead, Long Live Continuous Delivery

#156

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

naw I meant eulogize.

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

Re: Agile Is Dead, Long Live Continuous Delivery

#157
post #79
post #56

Earlier quoted context omitted.

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…

The big difference is that three months into a two year waterfall project, if someone complains that we're behind schedule, no one believes you or gives a shit. They keep hoping for a miracle. Three months into an agile project and everyone already knows there's a problem.

It's actually the opposite.

In a waterfall project you know you are behind schedule.

In an agile project you haven't planned two years ahead and so you simply adjust future expectations.

Post reply on HN