Even with Agile and Scrum waterfall will sneak in • Hacker News Board

Re: Even with Agile and Scrum waterfall will sneak in

#31

Post by detaro » Mon, Dec 06, 2021, 11:21 AM UTC

cube00 wrote: post #24

Flankk wrote: post #2

Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they're not important. If anything it puts needless pressure on devs who ideally should be free to think of solutions at depth. Sprints only make sense in that a team should be hustling in the early days. As the software matures, I don't think it's healthy to stri…

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

None of that is a requirement for agile processes. (Indeed I would argue that unless you have decided that's the best tool for your team, you're probably not being very agile. And no, when management of a big-co dictates how you work, they can call it "agile" as often as they want, it's not. Of course still extremely common, sadly)

Re: Even with Agile and Scrum waterfall will sneak in

#32

Post by frant-hartm » Mon, Dec 06, 2021, 11:22 AM UTC

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 described iterative/incremental development process. Scrum is one example of such process. Yes, Scrum is many little waterfalls.

But with Waterfall you Do the analysis of the whole project/product, check Specification of the whole.., check Design, check Implementation, check Internal testing, check UAT - this is the first time the customer sees the product, it's too late.

If you think it's stupid to do it this way you are right, that's the point. If you haven't seen this in real world then you probably didn't work on a government project or you were very lucky.

Re: Even with Agile and Scrum waterfall will sneak in

#33

Post by iamflimflam1 » Mon, Dec 06, 2021, 11:22 AM UTC

cube00 wrote: post #24

Flankk wrote: post #2

Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they're not important. If anything it puts needless pressure on devs who ideally should be free to think of solutions at depth. Sprints only make sense in that a team should be hustling in the early days. As the software matures, I don't think it's healthy to stri…

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

That is not agile it is SCRUM.

Re: Even with Agile and Scrum waterfall will sneak in

#34

Post by avian » Mon, Dec 06, 2021, 11:23 AM UTC

mr_toad wrote: post #15

Flankk wrote: post #2

Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they're not important. If anything it puts needless pressure on devs who ideally should be free to think of solutions at depth. Sprints only make sense in that a team should be hustling in the early days. As the software matures, I don't think it's healthy to stri…

> Waterfall was never that bad anyway. If you’ve never seen a project that wasted its entire time in the scoping and planning phase (and not produce anything), then you’ve never seen how bad waterfall can get.

Just to make a counter point, if you never spent your days in planning poker meetings, endlessly discussing hundreds of tiny scraps of yellow paper stuck to a white board (and never produce anything), you've never seen how bad Scrum can get.

Re: Even with Agile and Scrum waterfall will sneak in

#35

Post by nicoburns » Mon, Dec 06, 2021, 11:23 AM UTC

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.

Re: Even with Agile and Scrum waterfall will sneak in

#36

Post by ivan_gammel » Mon, Dec 06, 2021, 11:24 AM UTC

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…

This problem is not a problem of project management methodologies, but rather a problem of business strategy and scope management. If you want to fly to the moon with one shot, that is exactly it. Breaking down scope into smaller and better understood objectives is what will make things work and that should happen before a project starts. Afterwards it can be executed both as one big waterfall sprint for each objective or in some agile way with much higher chances for success and lower costs for cancellation.

Re: Even with Agile and Scrum waterfall will sneak in

#37

Post by littlecranky67 » Mon, Dec 06, 2021, 11:24 AM UTC

cube00 wrote: post #24

Flankk wrote: post #2

Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they're not important. If anything it puts needless pressure on devs who ideally should be free to think of solutions at depth. Sprints only make sense in that a team should be hustling in the early days. As the software matures, I don't think it's healthy to stri…

> 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/Scrumm (books, courses, experience) but rather learn-by-observation, i.e. "do what others do". And I have seen scrum master with zero expierience as a developer, just blindly trying to follow written guidelines in the books (scrum manual etc.) without being able to adopt those to a real development process.

Take for example your metion of standups: They are really valuable, and are not meant to "justify" your last 24h - but some managers think that this is the case, i.e. make sure your developers are not slacking and surfing on hacker news all day. Instead, one of the purposes is to detect blockages in any way. I mean if a dev takes very long for a task without it being justified (i.e. no other developer would understand why it would take so long), it might just be due to lack of skill and the dev might need some more training or senior assistance. It could also be that the task is more difficult than originally anticipated, in which case the team should possible act on it and change the scope etc. Sometimes it could also be a very eager junior dev, who just doesn't want to admit struggling with something out of pride or even fear etc. As a developer I can totally say, it actually takes quite some guts to come out in a group of devs and freely admit: "Hey, I struggle with that task, I don't know what I am supposed to do, or am not familiar enough to debug that code, can somebody help me on this?" - but admitting that you are not perfect is something lot of people struggle, especially juniors as they think they must be capable of doing everything.

Re: Even with Agile and Scrum waterfall will sneak in

#38

Post by CraigJPerry » Mon, Dec 06, 2021, 11:25 AM UTC

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…

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 two steps directly benefit the output product but he also argued this can’t scale to larger systems.

So various analysis and testing steps were added (none of which directly contributed to output, all were drags or costs on delivery - with the idea that they catch more problems earlier thus paying for their overhead), with feedback between them to catch earlier errors, and thus waterfall.

The agile mindset revolves around the idea that the other steps added are BS. The agile mindset solves for the impossibility of a 2 step analysis then code process at scale by reducing scale. It does this by using very small iterations and removing handovers between different parties.

Re: Even with Agile and Scrum waterfall will sneak in

#39

Post by [deleted] » Mon, Dec 06, 2021, 11:25 AM UTC

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…

[deleted]

Re: Even with Agile and Scrum waterfall will sneak in

#40

Post by sornaensis » Mon, Dec 06, 2021, 11:25 AM UTC

In my few years working as a dev, I am absolutely convinced that scrum and agile are the worst possible development practices you can have from the perspective of a developer, even though they are sold as 'developer centric' or that seems to be the impression a lot of people have at least.

It makes no sense at all to me to constantly have work interrupted with customer meetings that produce NO concrete specifications because everything is expected to be done just-in-time, on a whim essentially. It seems to nearly universally lead to dev whiplash, poor product architecture and large amounts of technical debt.

Many companies also seem to end up employing tens of people who don't actually have any role at the company-- they just show up an 'moderate' these 'ritual' meetings. I'm sorry, what exactly is the value add for having a person with no understanding of either development or product, running meetings that center around product development??? It just seems like a scam to create jobs for people with otherwise useless business degrees.

I'll take however many weeks of blistering specification followed by diligently developing against hard deadlines to the insanity of rolling technical debt and borderline abusive micromanagement that agile methods all but enforce. /rant