Hacker News Reader

Comment by closeparen | Hacker News Reader

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?

View on HN

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.

Reply on news.ycombinator.com