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…
Scrum is the new waterfall
41–50 of 183 posts
Re: Scrum is the new waterfall
#42Earlier 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…
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
#43Earlier 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…
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
#44Earlier 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…
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
#45Earlier 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…
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
#46Earlier 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…
> 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
#47This 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…
Re: Scrum is the new waterfall
#48It'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?
Most importantly, it gets you to ship.
Re: Scrum is the new waterfall
#49It'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.
Re: Scrum is the new waterfall
#50Earlier 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.
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.