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

11–20 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#11

Post by cube00 »

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.

The C-suite only hear "fast delivery" and ignore the other parts while also demanding the waterfall parts that suit the ways they need to work such as committing devs to deadlines one financial year out when funding bids have to be submitted.

There is something ironic about being ordered to estimate a 12 month work order while also being told make sure "it's agile" and delivered on time and on budget by ++currrentYear.

Re: Even with Agile and Scrum waterfall will sneak in

#12

Post by otagekki »

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!

A major French bank where I'm currently working at has implemented this method for its development teams... While we do have deadlines there is so few pressure compared to the other teams I had worked with before, that we actually have the luxury to build our features and being actually satisfied with what we're delivering

Re: Even with Agile and Scrum waterfall will sneak in

#13

Post by mytailorisrich »

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. What you describe does not oppose Agile and Waterfall.

Re: Even with Agile and Scrum waterfall will sneak in

#14

Post by OneTimePetes »

Waterfall is just a mapping of the dependency graph back into work-packages.

As all things are hierarchical in some way, large changes and additions, always lead to a larger change allover the graph, making it necessary to go all the steps back.

Change something large enough, and the process forces you back to the architecture drawing board.

Re: Even with Agile and Scrum waterfall will sneak in

#15

Post by mr_toad »

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.

Re: Even with Agile and Scrum waterfall will sneak in

#16

Post by drran »

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…

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

Re: Even with Agile and Scrum waterfall will sneak in

#17

Post by chewyfruitloop »

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 seems to be a pyramid scheme to get you to pay for the latest SAFe badge its overly complex and seems to be there to make management feel better about itself

Re: Even with Agile and Scrum waterfall will sneak in

#18

Post by littlecranky67 »

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 metrics/early warnings if something is not going properly (no project - waterfall or agile - is without problems during its lifetime). How would you asses the quality/progress of a project based on a couple of a specification or requirements documents 1-2years into the project with no (immediately usable) code being available? How would you asses if the approach taken after 3years in a project will be accepted by your endusers?

Waterfall is just a big black box to management and stakeholders with the hope that after 5years something usable will come out of it.

Re: Even with Agile and Scrum waterfall will sneak in

#19

Post by lelanthran »

mytailorisrich wrote: post #5
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…

I don't think it's any issue of individual raw productivity. It's about not wasting that work by focussing on building exactly what the customer wants as fast as possible. With pure waterfall you spend a lot of time writing and reviewing specs, then you spend a lot of time coding, then tests, then deliver. This means a longer lead time to working software and to any sort of feedback, and usually a waste of time in th…

> With pure waterfall you spend a lot of time writing and reviewing specs, then you spend a lot of time coding, then tests, then deliver.

(see my reply above, for some context and why I might be wrong :-).

My recollection of Waterfall is that there is always an "acceptance" phase at the end of every "fall"[1] - IOW, there is a sign-off by the stakeholders that what's in the phase is correct.

So your requirements are engraved in stone, your test protocol is engraved in stone, and your UAT is engraved in stone, and your "pilot performance acceptance" is engraved in stone.

If it turns out there is an error in any one of the phases above then that error, and that error alone, is signed off on and goes through all the phases (or "falls"?) again. Since this is more expensive the further in the falls the error is, there is pressure to get as much sign-off as possible for any issue before that issue proceeds to the next phase.

[1] I like the word "fall" to describe each phase of waterfall :-) I'm going to start using it more often and see if it catches on.

Re: Even with Agile and Scrum waterfall will sneak in

#20

Post by pydry »

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 basically the job of most middle management to do waterfall planning.

* Because if your managers manager wants deadlines, tough shit it's deadlines all the way down.

* Because ultimately, upper mamagement tends to prioritize control over profit even if that control is somewhat illusory.

Waterfall planning is kind of infectious, too - if the team does it in one area it spreads to others.

I would say that 90% of teams experience this kind of "waterfall whiplash".

I worked on a couple of teams where upper management didnt set deadlines or create roadmaps or anything. These rare occasions were the only time when I was entitely free of waterfall and we were way way more productive because of it. Like night and day.

However, 90% of companies can't even envision this, let alone do it. Most people dont even believe its possible - developers included.

I suspect this is one component of the secret sauce of high performing startups that defeat wealthier, more established incumbents.

Post reply on HN