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

121–130 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#121

Post by boffinAudio »

pjc50 wrote: post #110
boffinAudio wrote: post #101

Earlier quoted context omitted.

If you can't formulate actionable requirements, you're either not the domain expert, or not communicating properly with the domain expert. What your service looks like now and what it looks like in five years are obviously two different questions, but a proper analysis will divide the issue between now and 5 years from now and come up with requirements that fill the gaps. This doesn't mean things get set in stone and…

> > You cannot analyse how users will empirically interact with a product that does not yet exist. > I don't agree with this, as I believe it is very, very glib This implies that all A/B testing is worthless, which is .. surprising.

> > You cannot analyse how users will empirically interact with a product that does not yet exist.

You can certainly refine the software over time (A/B testing, if you will) to more closely attain the ideal, which you may not have well defined at the beginning of the project if you don't perform an adequate review of the needs of the user.

But you can certainly also complete a user analysis that produces requirements, which when fulfilled, solve the problem in its entirety for the user. These two extremes are not absolute - sometimes, if the analysis is incomplete, A/B testing can rescue the project regardless of how poorly the first analysis was performed - but A/B testing, it could be argued, is applying waterfall properly: iteratively, as intended... but by all means, call it 'agile' if that makes the difference to the team involved.

Re: Even with Agile and Scrum waterfall will sneak in

#122

Post by boffinAudio »

pjc50 wrote: post #113
boffinAudio wrote: post #104

Earlier quoted context omitted.

>What if the friction of authoring software was reduced to the point that the easiest output of "analyze" was .. working software? Well, the software world is certainly working hard - on one side - to reasonably attain this goal, while another big portion of it actively resists this advancement in human social services, such that it represents. Perhaps that is the key thing to all of this: "Until all of us are using…

> actively resists this advancement in human social services, > "Until all of us are using waterfall, many of us will have a hard time using waterfall. Now you've lost me, I've no idea what you're talking about with the first statement and the latter just sounds like cultism? People have valid reasons for iterative processes!

It goes like this: for as long as we are incompletely applying waterfall, someone else will attempt to refactor the natural process and call it something else, instead of just recognizing and then completing the waterfall process. This will be the state of things until either a) everyone abandons waterfall and/or calls it something else or b) waterfall is just so well understood as a natural law of the industry.

So its really more of a self-fulfilling prophecy situation, and yes in that regard, we are in a cult.

Re: Even with Agile and Scrum waterfall will sneak in

#123

Post by boffinAudio »

lbriner wrote: post #107
boffinAudio wrote: post #66

Earlier quoted context omitted.

Yes, developers and managers have to be involved in the full workflow. Why is this so hard?

It is hard because more people means more opinions. * Involving the developers in everything that the product team does as well as all of their own work is too inefficient. * Involving the wrong developer means you might not ask the right questions up-front. * Some developers are too negative and block things early on * Some developers are too positive and will say yes to everything even if it is unreasonable * There…

> more people means more opinions.

I'm sure 'manager people' have their own processes for this problem.

Re: Even with Agile and Scrum waterfall will sneak in

#124

Post by pjc50 »

boffinAudio wrote: post #122
pjc50 wrote: post #113

Earlier quoted context omitted.

> actively resists this advancement in human social services, > "Until all of us are using waterfall, many of us will have a hard time using waterfall. Now you've lost me, I've no idea what you're talking about with the first statement and the latter just sounds like cultism? People have valid reasons for iterative processes!

It goes like this: for as long as we are incompletely applying waterfall, someone else will attempt to refactor the natural process and call it something else, instead of just recognizing and then completing the waterfall process. This will be the state of things until either a) everyone abandons waterfall and/or calls it something else or b) waterfall is just so well understood as a natural law of the industry. So i…

This is just "communism can never fail, it can only be failed" but for Waterfall.

Re: Even with Agile and Scrum waterfall will sneak in

#125

Post by xondono »

Scarblac wrote: post #53
xondono wrote: post #9

To this day I still don’t understand how one can read the agile manifesto and somehow get to scrum. The whole thing is about processes, and tools (jira)… the complete opposite. The reason everyone ends up doing waterfall is that it’s not the devs who you need to convince when selling agility, is the chain of command. Being agile means having no long term plan. If the C-suite can’t handle that, you’ll never be agile.

In Scrum, the team should be self-managing. The Product Owner and Scrum Master are not managers or bosses, they're a customer representative and a secretary. I can see that working with "people over process". But then came certification, existing managers et cetera and that was lost.

> In Scrum, the team should be self-managing. The Product Owner and Scrum Master are not managers or bosses, they're a customer representative and a secretary. I can see that working with "people over process".

Except those are roles and processes, not people.

Putting people before processes and tools means treating people like adults and letting them work how they’re more comfortable.

Re: Even with Agile and Scrum waterfall will sneak in

#126

Post by drran »

lelanthran wrote: post #8
moritonal wrote: post #3

Earlier quoted context omitted.

Agile (if the culture incentivises honestly) does have the benefit of feedback. Rather than a black-box which "could" be done in a month, you can instead see that the team on-average under-estimates by 10 days, has x stories left, so it'll likely be done in 2-3 months at this rate. The downsides are that it opens up the team to feature-creep, introduced a pile of weird buzzwords, and can be massively wasteful if the…

> Agile (if the culture incentivises honestly) does have the benefit of feedback. Doesn't Waterfall incorporate feedback? In my memory and experience, it does. My memory of learning Waterfall back in the early 90s is a bit hazy, but I distinctly remember that one of the advantages touted was that mistakes earlier in the process of developing software are cheaper to fix than mistakes later in the process (no matter wh…

> Doesn't Waterfall incorporate feedback? In my memory and experience, it does.

No, by definition. Do you see a stream of water back to the beginning of waterfall in any waterfall on the planet? Nope.

Re: Even with Agile and Scrum waterfall will sneak in

#127

Post by zoomablemind »

theshrike79 wrote: post #92
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…

If it helps you can think of it like this: Scrum is just Waterfall, but with faster cycles. Traditional Waterfall(tm) is when you spend a year in analysis, a year in specifications, a year in requirement, a year in design... And then you put out a piece of software that's already outdated and doesn't do what the customer wanted or needed. But the company got paid anyway, so off to the next project. With Scrum you go…

>...And then you put out a piece of software that's already outdated and doesn't do what the customer wanted or needed.

Or software that was built on outdated foundations, like frameworks and providers which may have been "in-vogue" at the product conception, but deflated or advanced into maintenance-only stage by the product release.

Let's not forget that the competition is not sleeping meanwhile, so Waterfall is equally capable of pushing out half-cooked products just to be ahead or to meet obligations/expectations.

Re: Even with Agile and Scrum waterfall will sneak in

#128

Post by boffinAudio »

pjc50 wrote: post #124
boffinAudio wrote: post #122

Earlier quoted context omitted.

It goes like this: for as long as we are incompletely applying waterfall, someone else will attempt to refactor the natural process and call it something else, instead of just recognizing and then completing the waterfall process. This will be the state of things until either a) everyone abandons waterfall and/or calls it something else or b) waterfall is just so well understood as a natural law of the industry. So i…

This is just "communism can never fail, it can only be failed" but for Waterfall.

Inasmuch as software development and communism are both social services, yes.

Bad software fails to deliver on the social promise. As does any particularly bad political philosophy.

Re: Even with Agile and Scrum waterfall will sneak in

#129

Post by pydry »

jollybean wrote: post #70
pydry wrote: post #20

I noticed this as well. No matter how dedicated the team is to not doing waterfall, waterfall nearly always creeps its way back when anything that even smells like a deadline rears its head. Waterfall planning tends to get ramped up for four really common reasons: * Managers who simply cannot conceieve of non waterfall planning. * As a response to failure (ironic coz it tends to increase failure rate) * Because it's…

Waterfall creeps in because it's the most rational and linear way to do anything and we do it in all activities is our life without even thinking about it. When you build a deck, you 'Waterfall' it. Iterative development is slightly counter intuitive, until you write software for long enough, then it's definitely the intuitive approach. I suggest the simplest, easiest, best way to combat the urge to overplan is to br…

I actually started to notice after being a developer for a decade that a lot of people run face first into a metaphorical wall applying waterfall to their personal life where it didnt really work as well.

It's definitely "natural" though. I wonder if it's a cultural hangover from our agricultural past where lack of waterfall planning = dead.

Re: Even with Agile and Scrum waterfall will sneak in

#130

Post by Kim_Bruning »

fer wrote: post #117
lbriner wrote: post #95

Earlier quoted context omitted.

> done properly And herein lies the rub. If a project is more than 6 months to a year in duration, there is very little chance that what the customer now wants is what they wanted before. Requirements aren't created instantly on day 1 ready for dev, you could easily have several years of requirements, during which time people change, the world changes, the law changes, priority changes and then what? Even systems tha…

> If a project is more than 6 months to a year in duration, there is very little chance that what the customer now wants is what they wanted before. Depends largely on the customer. Just do anything defence, related to aircraft, or industrial control systems, more often than not, requirements are set in stone, and modifications require approval and consequent fees. Now, those industries throw a lot of money at actual…

For "small" projects having requirements set in stone (probably?) works fine.

The customer might claim something different, but for a couple of large and failing projects in industrial automation I've had to fight hard to be able to iterate and rescue them from the jaws of defeat.

You've had different experience?

Post reply on HN