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

Re: Even with Agile and Scrum waterfall will sneak in

#131

Post by xondono » Mon, Dec 06, 2021, 12:37 PM UTC

dtech wrote: post #81

iamflimflam1 wrote: post #30

Earlier quoted context omitted.

Indeed - the principals of the manifesto are very easy to read: https://agilemanifesto.org/ and https://agilemanifesto.org/principles.html The problem is people take the main points and use them to justify their own wants and needs. These are the main points: * Individuals and interactions over processes and tools This does not say you should not have any processes and tools. * Working software over comprehensive doc…

It's the next paragraph after those bullets: > That is, while there is value in the items on > the right, we value the items on the left more. Also keep in mind the manifesto came as a response to a "document-first" software design method, where basically the complete product was documented, planned and contracted before the first code was written.

* Individuals and interactions over processes and tools

* Working software over comprehensive documentation

* Customer collaboration over contract negotiation

* Responding to change over following a plan

And then you grab any Scrum guide and you’ll see:

* roles and processes: (Scrum master, product owner,…)

* tools: Scrum now is almost synonymous with Jira.

* Documentation mandates: “how to write proper user stories”, “how you should name, split and classify tasks”,…

I know a lot of people don’t consider it this way, but the backlog IS documentation.

The second most popular tool after Jira in Scrum teams is drumroll Confluence.

* Contract negotiation: Scrum defines a specific role (PO) with the main task of handling contract negotiations.

* Responding to change: Even the tools will complain if you change things mid sprint (because you’ll ruin the all important metrics!).

Re: Even with Agile and Scrum waterfall will sneak in

#132

Post by jollybean » Mon, Dec 06, 2021, 12:38 PM UTC

pydry wrote: post #129

jollybean wrote: post #70

Earlier quoted context omitted.

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.

It's not our 'past' it's out 'present'. 97% of our projects in real life are amenable to Waterfall.

Re: Even with Agile and Scrum waterfall will sneak in

#133

Post by theshrike79 » Mon, Dec 06, 2021, 12:57 PM UTC

zoomablemind wrote: post #127

theshrike79 wrote: post #92

Earlier quoted context omitted.

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

Exactly. I've seen this in military contracts where the rules are REALLY strict (and ancient).

Everyone on the project knows at one point that the resulting product will be outdated and useless, but neither side can call it quits. The one making the product needs to finish or they won't get paid, the one ordering said product can't cancel the project or they'll get sanctions according to the contract.

So they just go through the motions and produce something that'll never get used and is put straight into the bin.

Re: Even with Agile and Scrum waterfall will sneak in

#134

Post by drran » Mon, Dec 06, 2021, 1:09 PM UTC

jollybean wrote: post #63

drran wrote: post #16

Earlier quoted context omitted.

Water is a good, predictable process. It's just result bad. If the result is not important, then use waterfall.

"Water is a good, predictable process" No, Waterfall is bad precisely because of the inherent unpredictability of a given project. Never in all of history was a large software project speced out and built on time. Software lives in a dynamic environment, so the process has to be mutable. Maybe the answer is not 'Agile', but it's definitely 'agility'. If we set longer term term, rounded goals, but with smaller iterati…

SCRUM is just a bunch of small Waterfalls. In SCRUM, we have 2-week sprints. It's not important when one of the sprints will fail, because we will adjust following one. Moreover, we plan for first 2 sprints to fail anyway.

Why we should use something else, more complex, instead of Waterfall, for a single sprint? Waterfall is good enough and predictable enough for a 2-week sprint.

Yes, the result of a single waterfall will be bad, we plan for that, but accumulation of knowledge will lead us to success.

Re: Even with Agile and Scrum waterfall will sneak in

#135

Post by wiedelphine » Mon, Dec 06, 2021, 1:11 PM UTC

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…

the challenge I've always seen with putting the user hat on on so to speak is the difficulty in behaving as though you don't know how it works. I've seen enough user research where things that were obvious to the tram were not at all to the user.

Re: Even with Agile and Scrum waterfall will sneak in

#136

Post by unclebucknasty » Mon, Dec 06, 2021, 1:18 PM 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…

I hate to admit it but, In my experience, agile has brought productivity gains.

When practiced correctly what agile seeks to do is, not skip the steps you mentioned from the traditional waterfall model, but to apply them iteratively to individual feature sets in sprints, versus across the entire project.

I have seen many products fail to meet requirements and dramatically slip schedules under the waterfall approach. The project becomes too large and unwieldy, and too many assumptions are made that create dependencies for future features.

The reason I hate to admit agile's success is because it comes at a cost--namely there are frequently externalities such as lack of documentation and developer burnout.

Many agile implementations treat developers as cogs on a production line, responsible for essentially participating in automated CI/CD processes as a piece of software might be expected to do. And the relentless unending sprints can also easily take a toll.

Re: Even with Agile and Scrum waterfall will sneak in

#137

Post by db48x » Mon, Dec 06, 2021, 1:24 PM UTC

lelanthran wrote: post #62

db48x wrote: post #49

Earlier quoted context omitted.

Yes, though as originally documented the Waterfall process didn’t have much to say about iteration. It was simply left to the reader to realize that they would be releasing version 2.0 of their software a year or two later, and that they could incorporate feedback from the users of version 1.0. Most of the data about costs is quite limited too. A lot of the numbers that people quote come from the 60s, specifically a…

> Most of the data about costs is quite limited too. A lot of the numbers that people quote come from the 60s, specifically a project to develop software for a ground–to–air missile. Well that makes sense with my belief that WF aims to "deliver the system as a whole or not at all". There's no point in delivering an MVP G2A missile system that is not complete. > Certainly in that project fixing a bug after deployment…

>> Most of the data about costs is quite limited too. A lot of the numbers that people quote come from the 60s, specifically a project to develop software for a ground–to–air missile.

>Well that makes sense with my belief that WF aims to "deliver the system as a whole or not at all". There's no point in delivering an MVP G2A missile system that is not complete.

True! :)

Plus, the customer knew pretty much what they wanted from the start. Not much chance they watch the demo and then ask if it can be mounted to an airplane…

> To be sure, CI/CD pipelines make the fixing of bugs in the code cheap enough to simply deploy when you can. However, bugs in the specification aren't going to be cheaply fixed after deployment, and these are much more common[1] and hard to get correct than any other type of bug.

Yes, though in the agile model the idea is that the spec is just what the customer asked for two weeks ago (or whatever your sprint length is), after seeing how the program worked at that time. If there’s a misunderstanding and you correctly implemented the wrong thing, then the cost is at most the two weeks you spent on it.

Re: Even with Agile and Scrum waterfall will sneak in

#138

Post by ivan_gammel » Mon, Dec 06, 2021, 1:37 PM UTC

littlecranky67 wrote: post #55

ivan_gammel wrote: post #36

Earlier quoted context omitted.

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

Perfect example of unclear formulated goal of the project. You say "fly to the moon with one shot" and think it is completely defined. But the whole, year-long project would change in scope whether you mean "Land on the moon unmanned", "Land a man on the moon", "Land a man on the moon AND return him safely to earth" or "Flyby the moon, get close to surface and take some pictures". And if you now accept that any of th…

>Perfect example of unclear formulated goal of the project

That was exactly my point.

>And if you now accept that any of those above goals may be changed into another during project runtime, you understood why waterfall is not often the best idea.

I think you missed the entire idea of my comment. There is no sense in accepting that those goals will change and trying to start a project that aims to achieve one of them. They are too ambitious and broad in scope and need to be broken into smaller pieces (see Apollo program or SpaceX roadmap - both are focusing first on smaller objectives, that will clarify the next steps).

Re: Even with Agile and Scrum waterfall will sneak in

#139

Post by iamflimflam1 » Mon, Dec 06, 2021, 1:40 PM UTC

xondono wrote: post #131

dtech wrote: post #81

Earlier quoted context omitted.

It's the next paragraph after those bullets: > That is, while there is value in the items on > the right, we value the items on the left more. Also keep in mind the manifesto came as a response to a "document-first" software design method, where basically the complete product was documented, planned and contracted before the first code was written.

* Individuals and interactions over processes and tools * Working software over comprehensive documentation * Customer collaboration over contract negotiation * Responding to change over following a plan And then you grab any Scrum guide and you’ll see: * roles and processes: (Scrum master, product owner,…) * tools: Scrum now is almost synonymous with Jira. * Documentation mandates: “how to write proper user stories”…

https://martinfowler.com/articles/agile-aus-2018.html

Our challenge at the moment isn't making agile a thing that people want to do, it's dealing with what I call faux-agile: agile that's just the name, but none of the practices and values in place. Ron Jeffries often refers to it as "Dark Agile", or specifically "Dark Scrum". This is actually even worse than just pretending to do agile, it's actively using the name "agile" against the basic principles of what we were trying to do, when we talked about doing this kind of work in the late 90s and at Snowbird.

Re: Even with Agile and Scrum waterfall will sneak in

#140

Post by Confiks » Mon, Dec 06, 2021, 1:44 PM UTC

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…

> If you can't formulate actionable requirements, you're (...) not the domain expert

Yes, fine. So there is no (true Scotsman) domain expert. Grandparent's point is also just that actually building the application and seeing how users interact with it is a valid method of analysis either in a prototype phase or actual evolving production software.