Comment by gvand | Hacker News Reader

Comment by gvand | Hacker News Reader

Parent Full thread

- If you use Scrum[1] as a starting point to evaluate how your organization is structured, to reason about your processes and as a starting point to setup a process of continuous improvement (à la kaizen) that will turn your Scrum[1] in something unique to your situation and likely very different from where you started from: Yes.

- If you use Scrum[1] to turn everyone into a cog of a cookie-cutter system that you barely understand/control and that, for some form of deranged reverential respect, you apply mindlessly without questioning anything: No, may God have mercy on your soul.

In a more general sense, everything that is embraced aprioristically (methodologies, frameworks, languages, etc...) has the same damaging effects of a scam/fad.

The fact that most recent converts present Agile/Scrum as "the methodology that saved us from Waterfall!!" like if no one before ever did short iterative development cycles or tracked anything before, reminds me of those who drooled over nodejs for its nonblocking magic and its thaumaturgical webscale capabilities.

More reflecting, less bandwagoning.

[1] Replace with your favorite methodology.

Does anyone still use waterfall? I'd thought that had fallen by the wayside a long time ago in favor of less rigid processes ...

Yeah, currently working on a project implementing new core banking system via waterfall. You can still see it quite a lot in these extremely risk-averse industries (pharma, finance, insurance).

Usually we talk about waterfall being riskier, in that there is no validation that your approach is leading to a working system, or that the working system is meeting business needs, until the very end. The big bang integration step might fail, the testing might reveal show-stopper bugs, or the customer might go "oh, that's not what I meant," etc. but by the time you're learning any of that, it's too late.

Why do you think it's preferred in risk averse industries? Is the agile-partisan view of the relative risk incorrect? Missing something?

You don't do the whole implementation at once - you usually split it into several chunks/releases and everything becomes more manageable. I am a fan of agile where it makes sense - in projects/products where you have a strong uncertainty about the actual outcome/desired product. Then agile gets you there faster and cheaper.

But what people seem to forget about is that waterfall is actually cheaper in those cases where you have a clear understanding of the needs, the end product, and actions and tasks you need to do. This is usually the case in banking - you usually have a box product you need to customize and integrate (the toughest part, and processes are pretty much set (also strongly determined by the regulatory requirements). Hence, most innovations are just automation of specific process steps.

Another thing to consider is that the people in the bank are used to work in this way, so it removes some traction and gets you up to speed faster.

How is agile meaningfully different from small, iterative waterfalls?

Would you happen to have links to the text of regulation that specifies software development process? The only ones I can think of specify properties of the end result.

In agile (from my perspective) you rely on constant feedback from the stakeholders (customers, Product Onwer, sponsors) and iterate on it - that's why it's crucial to have short sprints so you can contain the uncertainty and make sure you're heading in the right direction.

In the 'iterative waterfall' you usually split the work into several domains, with each iteration taking months up to a year. E.g. when implementing new core banking system, the first release could be 'move the customer masterhip into the new system'.

Sorry for misunderstanding, I meant that business processes are usually derived from the regulatory requirements, not IT processes. The following implementation is then affected by those regulations - again, in a way that limits potential differences between the desired outcome and implementation choices.

There are a lot of contracts where the start and end date is non negotiable and already set in stone by some higher ups. You have to create a lot of documentation and feature list, give test cases for your work etc. Waterfall definitely works better in these type of work. Common at banks, pharmacies, governments... You can't really say at the end that some tasks did not make it to the last sprint but "hey it's in the backlog so no probs".

The most successful software I ever worked on was done with waterfall. This was back in about 2008 to 2012. I've no reason to think that company has changed, given how well it worked for them.

I do corporate training. Some of my students are management consultants. I'm always surprised how many have no experience with Agile.

Second that. You start at Scrum (or Kanban, or something) and then you talk to people using it and slowly tune it to your team.

Reply on news.ycombinator.com