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

71–80 of 157 posts

Re: Agile Is Dead, Long Live Continuous Delivery

#71

Post by optforfon »

lostcolony wrote: post #65
optforfon wrote: post #64

Earlier quoted context omitted.

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

So the way I have always handled it - Product owners create stories. These are titled things like "As a (type of user), I want to be able to X". The point of the title is to determine who this actually benefits. Then, they attempt to define it with acceptance criteria. These are a list of "what does it mean to solve this need". Ideally, it implies a set of tasks, and gives a decent starting point for QA to start test…

Thanks for the explanation - that really clarified things for me. The breakdown between story, task, sprint and milestone is very interesting and well thought out. Good estimate generation is the holy grail

Re: Agile Is Dead, Long Live Continuous Delivery

#73

Post by 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.

Re: Agile Is Dead, Long Live Continuous Delivery

#74

Post by timv »

chrisseaton wrote: post #52
coldtea wrote: post #44

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

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.

It depends.

Much like most "scrum" teams don't really do by-the-book Scrum, it was very rare to do by-the-book waterfall.

If you defined waterfall to mean

- get every requirement written up in absolute detail before you do any design

- finish the design in great details before you write any code

- if the design process identifies problems with the requirements (missing/ambiguous/etc), then stop the design work and go back to requirements phase

- write all the code before you start testing.

- if during development you find an issue with the design, stop development and go back to design

etc

Then I never saw any project that worked that way.

But it was quite common to have a requirements gathering exercise, write up a document that covered the requirements, get that "signed off", then do a multi-stage design phase (usually we'd start that before requirements were signed off, since the probability of the requirements being rejected in their entirety was pretty low), sign that off, and then move into development to implement that design. And then test the whole thing at the end once it was "done".

If at any stage we found missing requirements, that would get raised as a scope change. If, during development, we found that the design was broken in some way, we'd have a design change (which was usually lightweight and was a couple of emails saying "we can't do X, so we're doing Y, OK?")

Re: Agile Is Dead, Long Live Continuous Delivery

#75

Post by p4wnc6 »

jheriko wrote: post #49
p4wnc6 wrote: post #42

Earlier quoted context omitted.

When everyone misuses a tool, it's the tool's fault. And everybody misuses Agile.

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.

But why would you ever intentionally use (or vigorously defend) demonstrably bad tools? Just because you could do well with a bad tool doesn't mean you should or that you couldn't do better with easy-to-get other, better tools.

If you are forced to use an inferior tool like Agile, then sure, you want to make the best of it and be a craftsman who can still succeed.

That is an endorsement of being adaptable and self-reliant as an engineer, not an endorsement of Agile.

And if a tool is bad like Agile, it's useful to point it out and slowly steer the bureaucracy that feeds it into bastardizing whatever the next tool is, but hopefully inching forward to a better global state as well.

Re: Agile Is Dead, Long Live Continuous Delivery

#76

Post by lsc »

coldtea wrote: post #44

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

"Extreme Programming" always made me giggle. I mean, during that era, I was rarely seen without a can of mountain dew by my desk, but still.

Re: Agile Is Dead, Long Live Continuous Delivery

#77

Post by kensign »

strictfp wrote: post #26

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

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.

Re: Agile Is Dead, Long Live Continuous Delivery

#78

Post by tonyarkles »

jheriko wrote: post #49
p4wnc6 wrote: post #42

Earlier quoted context omitted.

When everyone misuses a tool, it's the tool's fault. And everybody misuses Agile.

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.

Sure, and I agree to a large extent, but if I'm doing woodworking and my blades are so fragile that they snap with the tiniest amount of friction, I'm probably not going to be very happy working like that for very long.

Re: Agile Is Dead, Long Live Continuous Delivery

#79

Post by hinkley »

barrkel wrote: post #56
voodootrucker wrote: post #38

Earlier quoted context omitted.

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

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.

Re: Agile Is Dead, Long Live Continuous Delivery

#80

Post by hinkley »

jheriko wrote: post #49
p4wnc6 wrote: post #42

Earlier quoted context omitted.

When everyone misuses a tool, it's the tool's fault. And everybody misuses Agile.

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.

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.

Post reply on HN