Live data from Hacker News

Scrum is the new waterfall

adambourg.com

91–100 of 183 posts

Re: Scrum is the new waterfall

#91
Straying away from any consideration of "how well agile was implemented", I've never been at a shop that seemed to get any real advantage by saying they are "agile". Although my experience is only 4 shops on that matter.

I would argue that since the method is deliberately left unclear, in reality it mostly profits to whoever wants to game it to his/her advantage. And if everybody wants the project to succeed as their respective primary goal, then you do not need such methodology anyway.

Do whatever seems to work best for the team, and don't name it. Don't waste time writing blog posts about how you found a new groundbreaking way to work, as these matters are subjective.

For example, now I work by asking whatever needs most attention right now, getting it done, and then asking again. No backlog, no notes anywhere, nothing. If we forget about something and it is important, it will come back up. It has no name and it works perfectly for us!

Re: Scrum is the new waterfall

#92
post #70

Earlier quoted context omitted.

1. I was not talking about Amazon. 2. The issue with the ESA code, like with railway systems, is: You write the code one time. You get a review. If you try to change just a single line later on – for example, to fix an issue that leads to the heating system on the ISS overheating – it will cost millions. Agile is a system that is not optimized for taking one version of software and running it for decades or centuries…

"The issue with the ESA code, like with railway systems, is: You write the code one time. You get a review. If you try to change just a single line later on – for example, to fix an issue that leads to the heating system on the ISS overheating – it will cost millions." I can guarantee you that 90% of the code in the Positive Train Control systems (the first real "new" control/sensor system in freight in decades) were…

And I can guarantee you that the software controlling the switches for the high speed rail and commuter rail networks in my state was written with waterfall.

The requirements were pretty clear, as there was a legacy system to be replaced and the changes to be made were not too hard to be found, the design was done in a DSL specifically written for the task of representing this project, the software was implemented, verified, and by now is under maintenance.

The requirements for a railway system rarely change, so agile is not really useful there.

Regarding "centuries": Some German companies stopped using the original Zuse pre-war computers in 2011. That’s over 70 years of software running constantly. Some banks still run code from the days before C. In the future, we’ll have more and more situations like that. And just like washing machines are sold with a lifetime guarantee, we’ll expect the same from the smart washing machine we’ll buy in 2025, too.

Re: Scrum is the new waterfall

#93
post #85

Earlier quoted context omitted.

Are you just telling me that waterfall is also agile? No, I'm obviously not communicating effectively. Documentation is a deliverable component of a software system. As a result, it can be tracked and managed just like any other deliverable component. In any real software system, the initial documentation will not reflect the finished system. That's inevitable – it's why we have errata. The difference between 'agile'…

The issue is when other software is built upon those initial documentation of your system. Third party services depending on you having a stable API, for example. You can’t just break support for them, so what do you do in agile?

Don't break support for them?

There are still requirements, there is still design. If you have a customer depending on your API, that is a requirement. Agile doesn't mean requirements go away.

Re: Scrum is the new waterfall

#94
post #55

Earlier quoted context omitted.

These statements from the agile manifesto are directly opposite to any kind of quality software No they are not. These statements are guidelines and principles to follow, and are not absolutes. If the requirements (i.e. acceptance criteria) for features you are working on include comprehensive documentation, then this can be delivered in the context of an agile framework.

The argument is: Agile is impossible. You have to document every feature before implementing it, because someone else will write software depending on it while you implement it. If you already document and plan every feature before implementing it, you aren’t doing agile, you’re doing waterfall. What you are suggesting – to plan, document, implement and test every feature one after another – is just waterfall for eve…

What you are suggesting – to plan, document, implement and test every feature one after another – is just waterfall for every problem separately.

Well, isn't that the core of any software development process? We're ultimately delivering features, and they all require planning, documentation and testing. The development methodology used doesn't change that. 'Agile' is the key word – change will happen, and being agile helps you to respond to that.

Re: Scrum is the new waterfall

#95
post #72

Earlier quoted context omitted.

"Agile works for web services, for small apps, but that’s it. Anything larger, or more complex, needs planning, thought, and design. And often needs refactoring." I hope you discover the flaw in this logic sooner in your career than later. I'll start with a hint: You are misreading the Agile manifesto. All successful teams and companies - Agile or not - do planning, thought, design. And the Agile community (which cam…

And I can tell you that even some cloud software, like the Elektronische Gesundheitskarte was developed with Waterfall. Often you have to design software interacting with dozens of other entities, all who are going to write software interacting with your system. And your system is supposed to be able to run for years or decades with minimal maintenance. Agile is far more suited for web apps, or small mobile apps, whi…

Healthcare.gov was also a healthcare application developed waterfall style and was an enormous failure on launch day because of it's interactions with 3rd party systems.

Re: Scrum is the new waterfall

#96
post #66

Earlier quoted context omitted.

Which, in reality, leads to everyone working on random things, just adding features and somehow patching bugs. No, it doesn't. Bad management and process leads to that. But often refactoring the system, rewriting subsystems, etc is necessary. Totally acceptable and something that can easily be included in agile development. If your software is working, but there is no documentation This is not a prerequisite of agile…

>> If your software is working, but there is no documentation > This is not a prerequisite of agile development. What I often see in "waterfail" projects is documentation that's inaccurate and reflects what once was the plan someone wanted to build.

This is so often the case, I agree. I can't count the number of times I've received a design document that details to the level of database field names – and of course, never bears any relation to the final product.

Re: Scrum is the new waterfall

#97
post #83
post #68

Earlier quoted context omitted.

"Working software over comprehensive documentation" over != instead of: "That is, while there is value in the items on the right, we value the items on the left more." And no, you probably wouldn't use agile to manage the project of heating the ISS. That is a very static problem space with unique requirements. Using the same framework to plan and build anything related to heating the ISS to build an HR system would b…

Well, that’s why you start testing what you can do, what the issues will be, etc while still working on the plan. You don’t decide to build a bridge out of a specific steel without testing in models which kind of steel is ideal for your case, or if you might have to change the shape of the bridge. But in the moment that others will build projects depending on your implementation being stable – in the bridge example,…

But it's not just simply the "correctness" of a solution that changes, that 3rd party API you're having to interface with might not return data in the same way you were expecting, the other company who were going to deliver the grid component can't do it in time anymore, half the dev team have fallen ill and are out for 3 weeks. No amount of planning up front can ever be sufficient, agile gives us devices to manage all of this that the traditional waterfall strawman lacks.

And then there's the solution itself not being suitable. Have you ever shown a solution built completely to spec in a waterfall-esque environment, only for them to say "oh, but it doesn't solve x"? or for them to start using it and suddenly realise there's some fundamental flaw in it? This is where agile comes in - you can regularly demo the software and make adjustments and reprioritisations as it comes together. It enables that conversation to be had and the change to be made when it's cheapest - early on, rather than when a huge app has been built on top of it.

Also - agile doesn't preclude stability. You can manage this with test suites (the top layer of the current project I'm working on's test suite is built against our documentation), we know if and when we've broken something because we're constantly emulating the third parties in your example using our software and asserting that it remains correct.

Re: Scrum is the new waterfall

#98
post #55

Earlier quoted context omitted.

The argument is: Agile is impossible. You have to document every feature before implementing it, because someone else will write software depending on it while you implement it. If you already document and plan every feature before implementing it, you aren’t doing agile, you’re doing waterfall. What you are suggesting – to plan, document, implement and test every feature one after another – is just waterfall for eve…

I'm very curious, what is your definition of waterfall?

The classical definition:

1. You research the actual requirements, including by testing some possible alternatives via mockups, etc. 2. You design the concept of your system, design APIs and interfaces. 3. You implement it. 4. You verify it matches the design and fulfills the requirements 5. You release it and maintain it.

Most importantly, after Step 2 your APIs don’t change anymore. This is especially important as third parties might rely on them.

Re: Scrum is the new waterfall

#99
post #55

Earlier quoted context omitted.

The argument is: Agile is impossible. You have to document every feature before implementing it, because someone else will write software depending on it while you implement it. If you already document and plan every feature before implementing it, you aren’t doing agile, you’re doing waterfall. What you are suggesting – to plan, document, implement and test every feature one after another – is just waterfall for eve…

What you are suggesting – to plan, document, implement and test every feature one after another – is just waterfall for every problem separately. Well, isn't that the core of any software development process? We're ultimately delivering features, and they all require planning, documentation and testing. The development methodology used doesn't change that. 'Agile' is the key word – change will happen, and being agile…

I responded to your sibling comment with the definition of Waterfall.

And every single comment defending Agile here was just "well, you can still document stuff before implementing it, and then verify it, and then maintain it". Which, effectively, is: Even if you’re agile, you can still do waterfall.

Great...

Re: Scrum is the new waterfall

#100
post #73
post #21

Whats wrong with waterfall? Surely mis-using waterfall was the culprit. I'm guessing same goes for Scrum. I've never followed true scrum so my opinion might be jaded however the devil generally lies in the implementation of the process. You cannot fit the same tire on a truck and a kid's tricycle, same way you cannot fit the same process for all development cycle. If you team needs clear direction and everything well…

Waterfall is literally a strawman methodology made up to illustrate the worst possible way to build software (short of having a million monkeys trying random programs), in order to serve as contrast to a way that actually works.

I wasn't really going towards defending waterfall[1] but lemme give it a try.

Waterfall might be not bad when you cannot have feedback mechanisms, you cannot roll out changes in phases, where requirements/scopes are fixed, tech stack is well defined and products have matured enough.

[1] : wanted to more say, use the right tool for the right thing in the right way. I don't think its easy but its doable.

Post reply on HN