Scrum is the new waterfall • Hacker News Board

Re: Scrum is the new waterfall

#121

Post by kuschku » Wed, Nov 11, 2015, 1:39 AM UTC

jdbernard wrote: post #114

kuschku wrote: post #98

Earlier quoted context omitted.

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…

Matthew already highlighted the concerns. So, hypothetically, what happens when just after you finish step 3 it is found that one of the core security mechanisms that the security of your life-critical product depends on and that was part of your published API is suddenly found to be insecure due to some new breakthrough in a research lab somewhere? Do you throw it all away and start over from step 1? Or what happens…

Okay, then let’s think about it.

You write your software, you deliver it, you discover that your software, running in pacemakers, is insecure.

What do you do? How do you send out security updates? How do you expect to be able to constantly update that software with agile?

There are many cases where updates are literally impossible.

Re: Scrum is the new waterfall

#122

Post by cechner » Wed, Nov 11, 2015, 2:00 AM UTC

kuschku wrote: post #23

badloginagain wrote: post #11

I've been at a few studios, all expounding how they're "Agile! Scrum! Fast-Moving!" And I've seen true "agile" horror shows. Stand-ups consisting of everyone either A) trying to prove they actually did work yesterday in as many words as possible or B) taking this as a chance to have a nice chat with everyone. Hour-long daily stand-ups are not agile. The worst though was the planning meeting for next sprint, where no…

At the university where I am, we were discussing today in one compsci class how agile is something that only works if you don’t care about consistent quality and only care about always having the newest, shiniest, greatest. And how, if you are working on software for ESA, or working for one of the largest internet retailers, or if you’re writing a control software for railway switches, waterfall is the only possible…

Ill reply to the root of all your comments, but this comment by you below sums up the problem:

> If your software has clear requirements, has a point when it is done, and only requires minimum maintenance after that, you aren’t writing agile.

This is simply not true. All 'agile' projects Ive worked on have had a complete-as-possbile analysis phase where we figured out the scope and the domain up front. This is not anti-agile at all, but is necessary on any project anywhere you are working on. (Agile is largely about avoiding 'big design up front', not 'big analysis up front'. There is a massive difference between analysis and design.)

Agile is about changing your plan when the _requirements_ change. Your API or whatever should change if your requirements change no matter what methodology you are using. But with waterfall you will not be able to and you will end up with a useless API.

Re: Scrum is the new waterfall

#123

Post by c23gooey » Wed, Nov 11, 2015, 2:01 AM UTC

kuschku wrote: post #106

rjspotter wrote: post #95

Earlier quoted context omitted.

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.

And now imagine Healthcare.gov was Agile and its API would change every month completely. And then imagine how every insurance would complain and how, after 2 or 3 months, everyone depending on healthcare.gov would have stopped supporting it because after the third rewrite of the parts of their software interacting with healthcare.gov’s API they’ve gone mad. Every time you interact with third parties you have to prov…

you seem to be mistaken about what Agile actually is.

i suggest reading the Agile manifesto [1] to get an understanding.

[1] http://www.agilemanifesto.org/principles.html

Re: Scrum is the new waterfall

#124

Post by kuschku » Wed, Nov 11, 2015, 2:06 AM UTC

cechner wrote: post #122

kuschku wrote: post #23

Earlier quoted context omitted.

At the university where I am, we were discussing today in one compsci class how agile is something that only works if you don’t care about consistent quality and only care about always having the newest, shiniest, greatest. And how, if you are working on software for ESA, or working for one of the largest internet retailers, or if you’re writing a control software for railway switches, waterfall is the only possible…

Ill reply to the root of all your comments, but this comment by you below sums up the problem: > If your software has clear requirements, has a point when it is done, and only requires minimum maintenance after that, you aren’t writing agile. This is simply not true. All 'agile' projects Ive worked on have had a complete-as-possbile analysis phase where we figured out the scope and the domain up front. This is not an…

The issue is that there are projects where changing your API is impossible, which means that using Agile is often a hopeless concept. Because if huge insurances already depend on your API, no matter how Agile you are, you can’t change it anymore.

And there are many cases where your code will be frozen at one point. Even if the requirements change.

Especially for Internet-of-Thing devices this can be very problematic, as no one is going to ever update them.

Re: Scrum is the new waterfall

#125

Post by matthewmacleod » Wed, Nov 11, 2015, 2:07 AM UTC

kuschku wrote: post #121

jdbernard wrote: post #114

Earlier quoted context omitted.

Matthew already highlighted the concerns. So, hypothetically, what happens when just after you finish step 3 it is found that one of the core security mechanisms that the security of your life-critical product depends on and that was part of your published API is suddenly found to be insecure due to some new breakthrough in a research lab somewhere? Do you throw it all away and start over from step 1? Or what happens…

Okay, then let’s think about it. You write your software, you deliver it, you discover that your software, running in pacemakers, is insecure. What do you do? How do you send out security updates? How do you expect to be able to constantly update that software with agile? There are many cases where updates are literally impossible.

I'm not sure how a 'waterfall'-style development lifecycle will help you here. Even if you front load all of your design, documentation and implementation, you will still find bugs and security flaws in your software. As an example, see every software product ever shipped!

I think you're maybe labouring under a misapprehension of what agile development means. In particular, you don't have to 'constantly update' deployed software in order to be able to develop in an agile fashion. You're free to follow the guiding principles to make sure you are able to cope with changes when they inevitably happen.

Re: Scrum is the new waterfall

#126

Post by kuschku » Wed, Nov 11, 2015, 2:08 AM UTC

c23gooey wrote: post #123

kuschku wrote: post #106

Earlier quoted context omitted.

And now imagine Healthcare.gov was Agile and its API would change every month completely. And then imagine how every insurance would complain and how, after 2 or 3 months, everyone depending on healthcare.gov would have stopped supporting it because after the third rewrite of the parts of their software interacting with healthcare.gov’s API they’ve gone mad. Every time you interact with third parties you have to prov…

you seem to be mistaken about what Agile actually is. i suggest reading the Agile manifesto [1] to get an understanding. [1] http://www.agilemanifesto.org/principles.html

I commented on it before in a sibling comment.

Also, please link the actual manifesto, not the intention behind it.

And that can be paraphrased as "People over tools", "Documentation doesn’t matter as long as it works", "Who needs a contract? Just collaborate with the customer!", "Plans? Why? Just follow the latest trends!"

And I have to disagree with them in every single point.

Documentation > Working Software (as others then can write their software interacting with yours before you are done),

Contracts > collaboration (if you want me to stay longer to do something, expand the contract and pay me extra),

Plans > change (if you just follow trends without ever structuring your design, you’ll end up with lots of code and no single person understanding all of it)

http://www.agilemanifesto.org/

Re: Scrum is the new waterfall

#127

Post by gnoway » Wed, Nov 11, 2015, 2:15 AM UTC

kuschku wrote: post #108

gnoway wrote: post #93

Earlier quoted context omitted.

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.

And if your implementation never changes, but you just do minor changes – isn’t that the maintenance phase of Waterfall again?

I don't like trying to make direct comparisons between Agile and Waterfall as if they are two separate mutually-exclusive approaches to development.

A product developed in an Agile process still has a 'maintenance phase'; the idea of software maintenance is not a Waterfall concept, it's a Software Development concept.

One thing I think you're having trouble with (maybe) is that this article was about Scrum, but you're attacking Agile. Scrum is an implementation of Agile, or maybe better characterized as a process facilitating Agile development, but it is not uniquely Agile. There are other Agile implementations/processes (Kanban, XP, etc.). Agile is more about attitude than implementation.

What Scrum is attempting to do is break down big ideas into small workable units, and help teams organize, assign, track and complete those work units efficiently. It separates the development cycle into several sprints: a team works a selected amount of items per sprint based on their capacity vs. the 'weight' of those items. If the development process using Scrum incorporates accepting changes to requirements or the design along the way, it's Agile. If it doesn't, Scrum can look a lot like a series of tiny waterfalls; you can absolutely have a Waterfall process where your teams organize and execute work like Scrum.

The most important thing to keep in mind is that neither Agile nor Scrum dictate what you consider to be a finished product, or a successful product. The standard of quality you added to one of your earlier comments is absolutely achievable using Scrum or another Agile process - in fact, it is the stated goal of Agile to turn out a high quality product which meets stated requirements.

Re: Scrum is the new waterfall

#128

Post by cechner » Wed, Nov 11, 2015, 2:26 AM UTC

kuschku wrote: post #124

cechner wrote: post #122

Earlier quoted context omitted.

Ill reply to the root of all your comments, but this comment by you below sums up the problem: > If your software has clear requirements, has a point when it is done, and only requires minimum maintenance after that, you aren’t writing agile. This is simply not true. All 'agile' projects Ive worked on have had a complete-as-possbile analysis phase where we figured out the scope and the domain up front. This is not an…

The issue is that there are projects where changing your API is impossible, which means that using Agile is often a hopeless concept. Because if huge insurances already depend on your API, no matter how Agile you are, you can’t change it anymore. And there are many cases where your code will be frozen at one point. Even if the requirements change. Especially for Internet-of-Thing devices this can be very problematic,…

I dont really understand this. "NF_REQ_00: API must not change"

Add verification tests to ensure API remains as documented. Every time someone checks in code your tests are run, break if something changes.

Every project has functional and non functional requirements, you write tests for them, your project is in a failure state if the tests are not passing.

Re: Scrum is the new waterfall

#129

Post by braythwayt » Wed, Nov 11, 2015, 2:32 AM UTC

kuschku wrote: post #60

braythwayt wrote: post #52

Earlier quoted context omitted.

Whenever the manifesto says “X over Y,” it does not suggest this is a strict dichotomy. I have worked in an agile manner on software that had extremely well-documented behaviour and all sorts of documented, objective requirements. The expression "Working software over comprehensive documentation” simply emphasizes what matters at the end of the day: Working software. If you need a certain amount of comprehensive docu…

Documentation can also be useful without working software. For example, when you have to interface with others. They can work on the software that depends on yours before you have even written a single line of code, and it will work. Software without documentation also can lead to serious issues – as in the "does the train continue running when the signal is broken" question I mentioned a dozen times now. In actual c…

> The best software is nothing without documentation

You know, it’s not enough to restate your own points, you have to read and absorb the things other people are saying.

Once again, “Working software over documentation” does not mean “Working software instead of documentation.”

It means that working software is more important than documentation, but both can be important. And it can be that documentation exists to make the software work.

If I said “Working software over software patterns,” that wouldn’t mean “Never, ever, ever use the Command Pattern, or Adaptors, or a Facade.” It just means that you use those things to make the software work. And if they are essential to making the software work, they are essential.

So you tell me that software is nothing without documentation, and I happen to agree. But software is also nothing without binaries. But that doesn’t mean “binaries over working software.” It just means, “build binaries as part of working software."

Re: Scrum is the new waterfall

#130

Post by calinet6 » Wed, Nov 11, 2015, 2:33 AM UTC

dragonwriter wrote: post #14

calinet6 wrote: post #12

Any system implemented without an understanding of how systems work, and how humans interact with them, will be painful. We need systems thinking, not any one prescribed process.

> We need systems thinking, not any one prescribed process. Problem is, its hard to get people doing systems thinking, especially about systems they are part of.

It's hard, but it's the only problem remaining.