Live data from Hacker News

Scrum is the new waterfall

adambourg.com

41–50 of 183 posts

Re: Scrum is the new waterfall

#41
post #35

Earlier quoted context omitted.

Why? What that is written in the Agile Manifesto precludes quality?

> Responding to change over following a plan Which, in reality, leads to everyone working on random things, just adding features and somehow patching bugs. But often refactoring the system, rewriting subsystems, etc is necessary. > Working software over comprehensive documentation If your software is working, but there is no documentation, this might work well for a website, but as soon as you go into control systems…

[deleted]

Re: Scrum is the new waterfall

#42
post #36

Earlier quoted context omitted.

That's not true. Quality and agile process are almost orthogonal. It is entirely possible to develop extremely high quality software within an agile environment and very possible to develop extremely poor software using waterfall. Agile doesn't mean "every engineer working on whatever they wanted." Ultimately quality software results when developers place a priority on writing correct software and when management is…

> Working software over comprehensive documentation > Responding to change over following a plan These statements from the agile manifesto are directly opposite to any kind of quality software. Documentation and Code Quality are some of the most important features. Your software is not working if it doesn’t exactly match its documentation. You can live with that in web software, but you’d end in jail if you tried to…

> That is, while there is value in the items on the right, we value the items on the left more.

Agile does not say that documentation is not important, nor does it say that a plan is bad. Documentation is worthless if the software doesn't work. The plan is crap if it no longer addresses the actual real-world requirements of the product.

Re: Scrum is the new waterfall

#43
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…

That's all just horribly inaccurate. There is no aspect of agile development that means that 'quality' (whatever that means!) cannot be delivered. Forget all of the fancy words and meetings and tools and techniques. At the core, agile development is about breaking work down into manageable, deliverable, testable parts, and being able to flexibly respond to changes in requirements when they inevitably happen – the goa…

I’ve commented twice on this before, I don’t know if I should comment the same again, but:

The type of development written down in the manifesto, and the type of development used by companies as Google or Facebook, is not in any way acceptable for critical systems. Or complex systems.

The worst part is when that interpretation of agile [1] is used for complex systems, like it is by Google or Facebook and similar companies.

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.

It’s rare that you can build a system where you don’t have issues with concurrency (and need to do timing analyses) or with interactions between multiple different systems.

I’ve seen these issues even when writing tiny projects like an Android app for an IRC bouncer.

And in any serious development, where your code is going to run critical systems for decades, you can’t just work agile.

    ----------------
[1] "as long as it works, documentation doesn’t matter", or "always have the newest, shiniest, greatest – no matter about plan or software design" – paraphrased from http://www.agilemanifesto.org/

Re: Scrum is the new waterfall

#44
post #36

Earlier quoted context omitted.

That's not true. Quality and agile process are almost orthogonal. It is entirely possible to develop extremely high quality software within an agile environment and very possible to develop extremely poor software using waterfall. Agile doesn't mean "every engineer working on whatever they wanted." Ultimately quality software results when developers place a priority on writing correct software and when management is…

> Working software over comprehensive documentation > Responding to change over following a plan These statements from the agile manifesto are directly opposite to any kind of quality software. Documentation and Code Quality are some of the most important features. Your software is not working if it doesn’t exactly match its documentation. You can live with that in web software, but you’d end in jail if you tried to…

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.

Re: Scrum is the new waterfall

#45
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…

That's not true. Quality and agile process are almost orthogonal. It is entirely possible to develop extremely high quality software within an agile environment and very possible to develop extremely poor software using waterfall. Agile doesn't mean "every engineer working on whatever they wanted." Ultimately quality software results when developers place a priority on writing correct software and when management is…

> Agile doesn't mean "every engineer working on whatever they wanted."

I totally agree. In my experience, it is very dependent on the group. When you are unlucky, you are in a group where for example one person always grabs the interesting parts. Because the group decides, it is very much about group pressure and clashing interests. A bad agile group can be similar harmful as a bad project manager.

One of the worst project managers, I experienced, insisted to divide the work "evenly" to the people in the group -- totally disregarding experience and abilities of the people. In a bad agile group, similar effects can happen.

In non-agile projects, there are dysfunctional groups and in agile projects there can be -- but in the later case, the problems can be worsened.

Re: Scrum is the new waterfall

#46
post #35

Earlier quoted context omitted.

> Responding to change over following a plan Which, in reality, leads to everyone working on random things, just adding features and somehow patching bugs. But often refactoring the system, rewriting subsystems, etc is necessary. > Working software over comprehensive documentation If your software is working, but there is no documentation, this might work well for a website, but as soon as you go into control systems…

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.

No, but agile says that software is still quality software, even when documentation doesn’t work. http://www.agilemanifesto.org/

It’s pretty clearly written down.

Re: Scrum is the new waterfall

#47
post #4

This is so negative. Look... the process can't be, "Hey you get all the time in the world to build undefined requirements with out providing any sort of insight." The reason you let people who don't code in to the meetings is because they pay your salary -- right? So translate. Give them something that makes them feel you are spending their money correctly. It's not all that hard to just define requirements, put a li…

If the primary way information flows between teams in your organisation is by throwing everyone in a room on a bi-weekly basis, you don't have much of an organisation. That's not professionalism, it's bad management under the heading, 'better than nothing.'

Re: Scrum is the new waterfall

#48

It's amazing to me the lengths organizations will go to avoid the one thing that actually works: hiring a small team of really good developers, paying them a lot of money and giving them hard ship date.

That seems like laissez-faire waterfall to me. The problem with the "hard ship date" is that it usually comes with a set of expectations for what is ready on that date: If you need software X on July 1, what happens when software Y becomes more necessary on April 15?

A hard ship date and flexible requirements is the way to do it: you force the issue and require your (great) developers to immanentize the software. It clarifies the mind and, assuming you didn't start off with absurd goals anyway, you get most of what you want.

Most importantly, it gets you to ship.

Re: Scrum is the new waterfall

#49

It's amazing to me the lengths organizations will go to avoid the one thing that actually works: hiring a small team of really good developers, paying them a lot of money and giving them hard ship date.

I've seen that go completely balls-up in several cases. The thing is, even really good developers can struggle to define what a complete and working system looks like.

Re: Scrum is the new waterfall

#50
post #36

Earlier quoted context omitted.

> Working software over comprehensive documentation > Responding to change over following a plan These statements from the agile manifesto are directly opposite to any kind of quality software. Documentation and Code Quality are some of the most important features. Your software is not working if it doesn’t exactly match its documentation. You can live with that in web software, but you’d end in jail if you tried to…

> That is, while there is value in the items on the right, we value the items on the left more. Agile does not say that documentation is not important, nor does it say that a plan is bad. Documentation is worthless if the software doesn't work. The plan is crap if it no longer addresses the actual real-world requirements of the product.

A software without perfect documentation is worthless.

Without documentation, you have to assume things. Does the train, if the signal is broken, stop or continue running? Does the radiation treatment machine, if you have a race condition, and two commands are executed at the same time, block, or just execute the last command?

Software without documentation kills.

Post reply on HN