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

111–120 of 157 posts

Re: Agile Is Dead, Long Live Continuous Delivery

#111

Post by zelos »

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…

"you're not going to design an application-specific framework that makes implementing features easy. It doesn't allow any space for experienced developers who have foresight,"

I wonder if this is an extension of 'programming by poking'[1]. You replace serious thought and planning with a piecemeal, try-it-and-see-what happens process.

[1] https://news.ycombinator.com/item?id=11628080

Re: Agile Is Dead, Long Live Continuous Delivery

#112

Post by lostcolony »

ozim wrote: post #101
lostcolony wrote: post #43

Earlier quoted context omitted.

"It takes longer to define the requirements than it does to code, and once coded they change mid-sprint" I've experienced one -or- the other of those, rarely both. The only times I've experienced both were due to product owners who wanted to be managers, to bring 'leadership', and so insisted on wasting my time with meetings that didn't actually lead to well defined stories. If I've had a product owner who wasn't a w…

Uh, for me sad part is when I try to make those people write stories in more detail like "what should happen if data fails to load", "what should be default state", "Ok we have adding for an element, how we handle deletes". I got question "So should we go back to the waterfall?". Because we are so agile that not everything should be specified up front. But they do not get the scope, single story does not fall into wa…

Yeah, that sounds like a broken process.

The story is the last possible moment of decision making before the developers go and develop something. Obviously it may need further refinement at a later date once you have learned something. But, by definition, you now know -everything that can be known before development starts-, because development is about to start. As such, anything, -anything- that remains unspecified, is, again, by definition, undefined. It may be worth explaining that if failure conditions remain undefined, then you will ignore them for convenience, because whatever you decide to do will almost assuredly be wrong. If the product owners want -any- say in what it does in the event of something going wrong, and don't want it to be a surprise, and require even more work, then now is the time to say something.

Re: Agile Is Dead, Long Live Continuous Delivery

#113

Post by gadders »

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…

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

Re: Agile Is Dead, Long Live Continuous Delivery

#115

Post by TeMPOraL »

terryf wrote: post #82
jheriko wrote: post #48

Earlier quoted context omitted.

http://agilemanifesto.org/ http://agilemanifesto.org/principles.html From the very first. > Individuals and interactions over processes and tools Have you seen this in practice and experienced how people work day-to-day? Leave them to their own devices and it varies a lot by personality. Some people need micro-management for instance... there is also thing that process is very important, and this point is self contra…

> ... and it varies a lot by personality ... But that is the point of the sentence. A process does not care about individual variation. What the manifesto is saying is exactly what you are saying.

Yeah, and that's a difference between a mature engineering discipline and software development. Though one could argue that software is so young as an industry that we have no clue what processes could be actually effective, so it's too early to set up one.

Re: Agile Is Dead, Long Live Continuous Delivery

#116

Post by ryanbrunner »

ternaryoperator wrote: post #81
gnaritas wrote: post #70

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…

People would refer to "The Software Development Life Cycle", which was by all means a waterfall-esque process (look it up on Google, you'll see the classic waterfall diagram used for it). The word itsself may have been coined as something to compare Agile against, but the process itself existed, and existed long after Agile had "won" in more traditional companies.

I ran projects that ran through a VERY traditional waterfall process as recently as 2010.

Re: Agile Is Dead, Long Live Continuous Delivery

#117

Post by wsc981 »

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…

What always annoyed me about Story Points is that it's a measure of complexity, not time. At least that's what Story Points are supposed to stand for.

When you state that a team should know how many Story Points it can handle, it would make much more sense to see Story Points as some measure of time. If you've completed last few Sprints 38 to 42 Story Points, with 2 full-time devs, than one could state that a single developer on average can finish 20 Story Points in Sprint. And if a Sprint is 2 weeks (10 days), that would mean maybe 2 Story Points per day for each dev.

Yet, in every business environment I've been in, the SCRUM fanatics always state that "No, story points are a measure of complexity". In practice, to me, this makes no sense. At least not if one wants to use historic Story Points to estimate how much work can be completed in the next Sprint.

Re: Agile Is Dead, Long Live Continuous Delivery

#118

Post by eru »

zelos wrote: post #111
barrkel wrote: 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…

" you're not going to design an application-specific framework that makes implementing features easy. It doesn't allow any space for experienced developers who have foresight, " I wonder if this is an extension of 'programming by poking'[1]. You replace serious thought and planning with a piecemeal, try-it-and-see-what happens process. [1] https://news.ycombinator.com/item?id=11628080

I don't know. Programming by poking works pretty well in Haskell, a language that's seldom accused of dumbing down. (And they've recently made it easier with typed holes.)

Re: Agile Is Dead, Long Live Continuous Delivery

#119

Post by tragic »

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…

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

Re: Agile Is Dead, Long Live Continuous Delivery

#120

Post by daemin »

With all this talk of Agile, continuous delivery, Waterfall etc, it reminds me of a Software Engineering course I did at University. Specifically one of the methodologies mentioned which was a Spiral model. The gist was that instead of having one monolithic Waterfall process, you would still do the steps in waterfall, but you would release more often and have smaller releases. So that after a few iterations you would spiral in on the desired solution.

Upon reflection this seems like a proto-agile methodology, and because it doesn't have its own set of buzzwords and extra processes it seems like it could be a good reactionary (as a reaction against full Agile) methodology to use.

Post reply on HN