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

Even with Agile and Scrum waterfall will sneak in

amazingcto.com

Post reply on HN
Print view View original

71–80 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#71

Post by dtech »

ankurdhama wrote: post #60
littlecranky67 wrote: post #18

Earlier quoted context omitted.

The problem with waterfall to my experience is not immediately visible to developers or directly concerns developers, but rather the stakeholders and managers. Almost always, your customer doesn't know what they want - they think they do, but they don't and will only realize this after you finished development and have a visible system demo/field test. Additionally it is really hard for project management to get metr…

> Almost always, your customer doesn't know what they want - they think they do, but they don't I honestly don't understand this statement. Could you provide an example to elaborate on this point? I have read it at so many places but it sound more like the fashionable thing to say. The "need" have a starting point, may be a very high level problem statement, and then through analysis, back and forth question answerin…

it's an old and widely accepted truism. I don't know how much formal research had been done into it.

Re: Even with Agile and Scrum waterfall will sneak in

#72

Post by boffinAudio »

frant-hartm wrote: post #32
boffinAudio wrote: post #10

I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these ste…

> There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these steps, does an Implementation and Testing phase .. then the issue has to be validated/verified with a Qualification step, and then it gets released to the end user/product owner, who sign off on it. If you do this feature by feature than you have descr…

I've worked on all kinds of projects, and every single time the project failed, the tooling and methodology were blamed, not the individuals. This is the #1 cause of failed software projects - the inability for individuals to take responsibility for parts of the workflow, for which they are incompetent, and not subsequently working on improving that competence at an individual level.

But true, breaking larger problems down into smaller units (Agile/Scrum) is an effective way for a "manager" to help their developers - but I argue this is non-optimal for sociological reasons, not technical: Adherence to a cargo-cult is a function of laziness, not competence.

Re: Even with Agile and Scrum waterfall will sneak in

#73

Post by drran »

zogomoox wrote: post #6

A version of this is Scaled Agile (SAFe) which somehow manages to combine the worst of both worlds. If you see your organization preparing to go SAFe, run!

SAFe works just fine when Agile is perfected, i.e. about 5 years after every day practicing of Agile. If you have no Agile to begin with, then you cannot scale it.

Re: Even with Agile and Scrum waterfall will sneak in

#74

Post by buro9 »

mytailorisrich wrote: post #13
buro9 wrote: post #7

The extremes were bad, not the essence of the idea. Stay lightweight and you can have the best of everything. When anything is non-trivial to implement, i.e. it has dependencies, then it benefits from _some_ waterfall planning. Meaning to think before the work begins about the approach being taken, all of those dependencies, and who you need to engage and when... tada, you've made a GANTT chart in your head and are n…

> then it benefits from _some_ waterfall planning. Meaning to think before the work begins about the approach being taken, all of those dependencies, and who you need to engage and when... tada, you've made a GANTT chart in your head and are now waterfall because you put some thought into the dependencies and the order of execution. Agile does not mean that you should forego all of this and code first, think later. W…

I know :)

But people did take agile to an extreme and they did forego the essence of other processes.

I feel that the line "everything in moderation" applies well to project management. Moderation being the key part.

Re: Even with Agile and Scrum waterfall will sneak in

#75

Post by bregma »

boffinAudio wrote: post #10

I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these ste…

Coders just want to code. Waterfall means you have to wait before you code, and plan, and organize. Agile means you just start coding, and code and code and code until you leave and someone else has to clean up the mess.

This is no different than most other activities in life. See the Stanford marshmallow experiment.

Re: Even with Agile and Scrum waterfall will sneak in

#76

Post by pmoleri »

littlecranky67 wrote: post #18
boffinAudio wrote: post #10

I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these ste…

The problem with waterfall to my experience is not immediately visible to developers or directly concerns developers, but rather the stakeholders and managers. Almost always, your customer doesn't know what they want - they think they do, but they don't and will only realize this after you finished development and have a visible system demo/field test. Additionally it is really hard for project management to get metr…

I consider fleshing out customer requirements part of the engineering process. You cannot expect the customer to properly communicate what they want/need. That doesn't mean Scrum, you have many other tools at your disposal, presenting the customer with scenarios to challenge their requirements, use interactive prototypes or even paper ones. All of them far cheaper than implementing the wrong thing.

I agree about the pitfalls of not seeing something usable until it's very late and how to measure progress. The opposite is also true however, you make some easy non-scalable PoC and it looks like a huge progress when it actually can't or shouldn't be used as a foundation for anything.

Re: Even with Agile and Scrum waterfall will sneak in

#77

Post by hamasho »

nicoburns wrote: post #35
boffinAudio wrote: post #10

I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these ste…

"Agile" processes still have all these steps, they just repeat them in a loop on a much smaller timescale. This allows for a lot more flexibility, and for feedback from the qualification of the first iteration to go in as input to the analysis stage of the next iteration.

I agree with that.

But it's worth noting that we need to spend more time on task management with a shorter development cycle. In waterfall or scrum or whatever, one development cycle often comes with listing tasks, prioritizing, planning, developing, retrospection, or something similar. If the cycle is long, we can spend more time on each process. But if the cycle is short, we rush to complete each process and can't spend enough time understanding each process's meaning. So I focus more on consuming as many stories as possible. I never think about the product's goal and how I can contribute to it.

So we have to spend more time teaching the purpose of each process. Or we end up as a failed agile development.

Re: Even with Agile and Scrum waterfall will sneak in

#78

Post by swiftcoder »

No matter what process we adopt, we'll always have waterfall as long as the sales side of the house needs predictable features and release dates. There isn't really anyway round that - if we can say with confidence that we'll release features X, Y, and Z in a release 6 months from now, then we don't have room for more than localised iteration.

Agile-ish systems work great when you don't have pre-determined delivery dates, but unless you are an internal-facing team with only a backlog of tech-debt to burn down... who is actually in this position?

Re: Even with Agile and Scrum waterfall will sneak in

#79

Post by ankurdhama »

littlecranky67 wrote: post #69
ankurdhama wrote: post #60

Earlier quoted context omitted.

> Almost always, your customer doesn't know what they want - they think they do, but they don't I honestly don't understand this statement. Could you provide an example to elaborate on this point? I have read it at so many places but it sound more like the fashionable thing to say. The "need" have a starting point, may be a very high level problem statement, and then through analysis, back and forth question answerin…

It is very easy actually. We often a business uses Excel for their processes and flow, that is they have excel sheets that they edit, copy, send around and merge back. Now, we all know the problems that exists with this approach, and even the customer knows that. But that doesn't mean they can perfectly describe how any application that gets rid of those excel files should look like.

But isn't the problem statement itself what you need from customer? My idea is that the customer approached you with the problem statement and their expectations is that you would provide possible solutions to it instead of the customer defining the solution exactly and just asking you to "code" it.

Re: Even with Agile and Scrum waterfall will sneak in

#80

Post by drran »

boffinAudio wrote: post #65
CraigJPerry wrote: post #38

Earlier quoted context omitted.

Royce argued that only in small software systems can you do a little bit of analysis then a little bit of coding then be done with the project. He proposed waterfall as a way to build larger software systems. He argued that these 2 steps were the only direct value steps in developing software - figure out what the problem is then write a little code to solve it - he acknowledged this was the perfect ideal since the t…

Agile has failed the industry precisely because the other steps are NOT BS. Unfortunately, de-programming Agile-adherents is more work than actually just doing those natural, proper steps.

Agile is just 20-30 small waterfalls instead of big one. How small a waterfall needs to be to fail?
Post reply on HN