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

101–110 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#101

Post by boffinAudio »

ivanbakel wrote: post #84
boffinAudio wrote: post #56

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. This just indicates a failure to perform a proper Analysis/Speci…

>This just indicates a failure to perform a proper Analysis/Specification/Requirements phase, with relevant qualifications steps. It doesn't matter if you're a Manager or a lowly Developer - if you can't adequately qualify the requirements and specifications, the analysis is simply not complete. But that view of requirements is not borne out by the reality for most projects. You're presuming that it's possible to gat…

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 aren't adaptable to changing needs - when this condition is identified, the manger/developer need only apply the workflow again, and revise the specifications with the updated data, and a new development plan can be formulated. Maybe this is 'agile', but again - it speaks to the fact that waterfall is a naturally occurring phenomenon in engineering/technical matters, and thus should be applied consistently, completely, in order to provide fruitful results.

> 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. You can of course empirically interact, by wearing the user hat. Too often the developer/manager/user hats are considered adversarial - but when the decision is made to be flexible about which of these hats one is wearing, during analysis, makes all the difference between whether your product is successful or not. Software is a social service - rigid developers who cannot put on the user hat, are not providing the most intrinsic aspect of that service in their field.

>You're presuming that it's possible to gather the "ideal requirements" when the project first starts, with enough due diligence - and also, that those requirements are fixed.

I make the claim that this ideal can be attained, by ensuring that the early steps in the waterfall process are actually applied. You are correct in noting that "when you don't do things right, right things don't happen", however ..

Re: Even with Agile and Scrum waterfall will sneak in

#102

Post by andrewingram »

In my mind agile, is about avoiding committing to a particular direction before verifying that it's the right one, and in a lot of cases (particularly in the startup world), verification requires shipping to potential customers.

Agility doesn't promise fastest time to delivery. It's acknowledging that you'll probably build the wrong thing, so it's about making it easier to course-correct.

The failure state of agile (waterfall hidden behind agile ceremony) is usually triggered by leadership/management teams not willing to _truly_ delegate. Once process becomes dominated by accountability and visibility (which I've never seen not happen with Scrum), rather than supporting the people doing the work, all bets are off.

Re: Even with Agile and Scrum waterfall will sneak in

#103

Post by lbriner »

bregma wrote: post #75
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.

So you are saying that agile happened because of coders and not because there were fundamental problems with using waterfall on large projects?

No part of agile says that you get rid of planning and organizing, it is just done in smaller slices in shorter cycles.

Having used both over 25 years, I wouldn't look back at waterfall for any project except the very smallest. No-one allows you to lock some requirements in for 5 years any more, something that was accepted back in the day. I have plenty of examples of waterfall projects that delivered a number of things that simply weren't required any more and that was a failure of a long-tail project plan.

Agile also allows you to work iteratively on a project that is never finished i.e. SaaS, which is not possible with waterfall.

Re: Even with Agile and Scrum waterfall will sneak in

#104

Post by boffinAudio »

pjc50 wrote: post #85
boffinAudio wrote: post #59

Earlier quoted context omitted.

"Agile" just means "analyse the situation until you have properly fleshed out specifications, great requirements that will solve the problem as described, and a proper plan for development". Still, "Analyze until Completion" doesn't need to be couched in fancy new-age terms that someone will get paid to teach everyone ..

In startup land, it's often quicker to ship software than analyze, and this tends to win in the market. The "analyze" worldview assumes that the easiest and most accurate format for the output of an "analyze" process is some natural language text and maybe diagrams and a powerpoint or two. What if the friction of authoring software was reduced to the point that the easiest output of "analyze" was .. working software?…

>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 waterfall, many of us will have a hard time using waterfall." I'm not sure I like where this leads, so I'll just agree with you that sometimes you just have to crash rockets.

Re: Even with Agile and Scrum waterfall will sneak in

#105

Post by HelloNurse »

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…

The "extremes" are good in their appropriate extreme niche: spacecraft flight control software is definitely engineering and it has to be perfect the first time (no exploration or iteration), while the only prudent and efficient way to publish a website with a day's notice requires a rushed MVP and then as many small edits and additions as fit in the available time.

In the middle of the spectrum there are varied tasks, for which an excess of waterfall can force the creation of low-value documents (e.g. hundreds of pages of up-to-date screenshots of complex forms instead of describing in detail only interesting data and interesting workflow and honestly stating that UI layout will be arbitrarily reorganized according to stakeholder feedback after every demo until they are happy) and an excess of agility can be an obstacle to correct design (e.g. publishing a mock incomplete version of some service without taking a couple of days to determine whether the data needed to actually implement it is going to be available).

Re: Even with Agile and Scrum waterfall will sneak in

#106

Post by boffinAudio »

pjc50 wrote: post #94
boffinAudio wrote: post #89

Earlier quoted context omitted.

>> Analysis, Specifications, Requirement >These tend to be inadequate, incomplete, or .. >> Qualification >.. at this point the customer discovers that what they asked for does not actually solve their problem. I disagree. If you are properly isolating your work into an "Analysis" phase, you will properly flesh out the issues and the subsequent specifications and requirements will be complete - sufficient to the task…

> If you are properly isolating your work into an "Analysis" phase, you will properly flesh out the issues and the subsequent specifications and requirements will be complete - sufficient to the task of formulating a development/implementation plan. But if you don't take care to complete a proper analysis - then no, you won't formulate specs or req's properly, either. But what if that doesn't happen? (This seems to p…

>Australian dollars

Perhaps Waterfall (and its cousins) needs an addendum: Check for and Remove Corruption.

Re: Even with Agile and Scrum waterfall will sneak in

#107

Post by lbriner »

boffinAudio wrote: post #66
flohofwoe wrote: post #48

Earlier quoted context omitted.

> .. then the Developer takes in the materials of each of these steps IME this is the main problem, the "Developer" must be heavily involved from step 1 (and work in a close feedback loop with QA). Everything else follows automatically in ever smaller iteration steps. Software development is first and foremost experimental research work, not a factory line. E.g. if a specific software development task feels like bori…

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 is not always a clear authority between product owners and developers * A lot of decisions are based on company priorities that might need someone outside of the product/development team to argue for

Re: Even with Agile and Scrum waterfall will sneak in

#108

Post by theshrike79 »

littlecranky67 wrote: post #37
cube00 wrote: post #24

Earlier quoted context omitted.

> As the software matures, I don't think it's healthy to strive for squeezing your devs for every last drop of productivity. This is why I hate agile, it's incredibly stressful. Daily stand ups to justify your last 24 hours, affirmations in said stand ups which must begin with "Yesterday I committed to... and did/did not achieve this because..." followed by "By this time tomorrow I commit to delivering....". JIRA bur…

All you say is agile not implemented correctly (which is very common). I am a contractor and switch projects and development environments very often. I've seen agile working really well when it is properly implemented, and really poorly when it is wrongly implemented. The biggest problem I see that people never really get educated in agile. I see PMs/POs/Developers etc. that never had any formal training in agile/Scr…

> I see PMs/POs/Developers etc. that never had any formal training in agile/Scrumm (books, courses, experience) but rather learn-by-observation, i.e. "do what others do".

Ahh, good old cargo cult Scrum.

I've seen a bunch of this when consulting. People use all the right terms, but nothing else really makes sense. There is a "daily standup" done sitting down and it lasts up to 45 minutes. There are "sprints" that last from 2 to 12 weeks with no deliverables. There is grooming, which is just chatting and maybe looking at Jira a bit.

Scrum can be done right, but it requires the WHOLE organisation to be trained to do it properly. Preferably by a very very very expensive Scrum Consultant so that even the C-staff put some weight in their words. (expensive == good)

Re: Even with Agile and Scrum waterfall will sneak in

#109

Post by boffinAudio »

drran wrote: post #80
boffinAudio wrote: post #65

Earlier quoted context omitted.

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?

Honest opinion: Its not a matter of size. Its a matter of completeness. Agile or waterfall processes fail if you omit the Qualification step, or if you don't ensure that the analysis produces actionable requirements, or clearly formulated specifications that lead to requirements, user/technical/or otherwise.

Re: Even with Agile and Scrum waterfall will sneak in

#110

Post by pjc50 »

boffinAudio wrote: post #101
ivanbakel wrote: post #84

Earlier quoted context omitted.

>This just indicates a failure to perform a proper Analysis/Specification/Requirements phase, with relevant qualifications steps. It doesn't matter if you're a Manager or a lowly Developer - if you can't adequately qualify the requirements and specifications, the analysis is simply not complete. But that view of requirements is not borne out by the reality for most projects. You're presuming that it's possible to gat…

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.

Post reply on HN