Live data from Hacker News

Scrum is the new waterfall

adambourg.com

61–70 of 183 posts

Re: Scrum is the new waterfall

#61
post #43

Earlier quoted context omitted.

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 comp…

Agile works for web services, for small apps, but that’s it. That's plainly not true. Many large applications are written by agile teams. Anything larger, or more complex, needs planning, thought, and design. And often needs refactoring. Yes – none of these things are banned by agile development. Refactoring is positively encouraged! It’s rare that you can build a system where you don’t have issues with concurrency (…

> Absolutely. This has no relation to the development process used to build those systems.

Yes, it has.

Agile encourages people adding features without previously planning every single interaction of the feature with every other piece of software. Which means, Agile encourages writing code without being sure it will interact safely with other parts.

Re: Scrum is the new waterfall

#62
post #2

I don't really agree with this - Scrum isn't really easy to do but in many situations it is the simplest approach to take. If you need to monitor your progress in 'real' terms (i.e., whats actually completed) Scrum is pretty much the minimum ceremony you can get away with in my experience. If you don't need to do that, say if you don't have a deadline that you need to know you wont hit ASAP, then Scrum is likely not…

It sounds like you dont really know what the purpose of scrum is. Unfortunately, every response to "we tried process/technique X and it failed" in this space is ultimately "you didn't understand it" or "you did it wrong". So no true scrum would have... No true Agile shop would have... And where does that get us? It appears that the success rate of people understanding and implementing these things is very close to 0%…

well allow me to put a note here as someone who uses it successfully regularly.

Also I explain several times why he doesn't seem to understand it - having non-technical people running his scrums, working overtime and screwing up their velocity measurements, not being able to cope with changing requirements. These are things that scrum was built to _directly address_.

I say again, if you're criticising scrum as being too onerous, you are probably either using it wrong or using it where you shouldnt (where you dont need to track your progress.)

Re: Scrum is the new waterfall

#63
post #56

Earlier quoted context omitted.

You are ignoring what I am saying – these are guidelines and principles to follow in development processes, not absolute requirements. If a requirement for the system you are delivering is comprehensive, complete documentation, then you can deliver that. The point is that "comprehensive documentation" without "working software" is useless.

No, it is not. Your software might be working later on – and at the same time, someone else can write software depending on yours, based on just the documentation. Additionally, software without documentation leads to issues like "does the train continue running when the signal is broken?", and similar ones.

No, it is not. Your software might be working later on

It might be, but it almost certainly won't be. See the errata to any set of documentation. But this is a digression – if the acceptance of your product or feature requires documentation of interfaces in advance, then that's a requirement that can be met regardless of the development process that you use.

Additionally, software without documentation leads to issues like "does the train continue running when the signal is broken?", and similar ones.

No, that's what incorrectly designed, implemented or tested software leads to. But again – if documentation is required, using an agile process in no way restricts your ability to meet that requirement

Re: Scrum is the new waterfall

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

How many lines of code have you written that are in production with actual users right now?

I’ve worked on some agile projects from others that I picked up and had to "fix", where we, now, after 2 years of trying to work with them, have decided to completely rewrite them from scratch.

Every agile project I’ve seen yet was just a huge ball of technical debt. It worked, it had few user-facing bugs, but adding features was impossible, and the documentation was "whatever the software does". Completely matched the agile manifesto "working software over documentation" and "change over plan".

Re: Scrum is the new waterfall

#65
post #19
post #8

Earlier quoted context omitted.

edit: I just noticed they said 'sprint commitment', and that they should adhere to it even if it runs overtime. This is probably the most wrong part of the article - you get done what you can, and let it affect your velocity. It is this velocity that is the central indicator of how much you can realistically achieve

I read "adhere to the sprint commitment" as being an undesirable aspect of Scrum that the author was complaining about, not something that Scrum is lacking. It's certainly one of the bad parts of Scrum as commonly interpreted; c.f. http://www.peterkretzman.com/wp-content/uploads/2014/10/Aski... . (That's why newer docs tend to substitute "commitment" with "forecast", to clarify the Manifesto author's intent).

interesting - I recently heard someone call it a forecast and thought 'man why don't they use that term in scrum?'

Nice to know that they actually do (I havent read up on it in some time, probably should)

Re: Scrum is the new waterfall

#66
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.

What I often see in "waterfail" projects is documentation that's inaccurate and reflects what once was the plan someone wanted to build.

Re: Scrum is the new waterfall

#67
post #56

Earlier quoted context omitted.

No, it is not. Your software might be working later on – and at the same time, someone else can write software depending on yours, based on just the documentation. Additionally, software without documentation leads to issues like "does the train continue running when the signal is broken?", and similar ones.

No, it is not. Your software might be working later on It might be, but it almost certainly won't be. See the errata to any set of documentation. But this is a digression – if the acceptance of your product or feature requires documentation of interfaces in advance, then that's a requirement that can be met regardless of the development process that you use. Additionally, software without documentation leads to issue…

But when you have to document and plan everything you write before you do so, isn’t that again waterfall?

Are you just telling me that waterfall is also agile?

Re: Scrum is the new waterfall

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

"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 be overkill. Right tool for the job, etc.

I've worked on both good and bad agile projects - all have involved managing change. The good ones didn't involve throwing a plan out & doing what you want. They merely accepted that when you start building a solution, you lift rocks and uncover requirements that you never envisaged having. In an agile environment, you can deal with that - bring those things onboard, reprioritise and rescope, giving an accurate idea of when a product is going to be delivered. In a traditional waterfall environment, these same requirements get left until the now-woefully inadequate product is built, and useless to anyone.

Re: Scrum is the new waterfall

#69
post #43

Earlier quoted context omitted.

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 comp…

"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 came out of the Smalltalk community) also invented refactoring (in the disciplined sense, along with the first Refactoring IDE).

Here's another hint: very few actively run systems in financial markets/brokerages were written with a waterfall method since the mid 90s. Not all were developed with great agile either, but let's just say they were "incremental and iterative". These are complex systems. They're not designed for 8 months on paper.

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

This is somewhat true, assuming you have stable requirements. But almost no software, even for complex systems, runs for decades without an update. It just doesn't happen anymore except in the most constrained environments (space exploration, signal/control systems in dark territory, etc.)

If your career trajectory is working for the military building weapons guidance systems, or an FDA manufacturer building blood pressure monitors, you also may come close to this ideal.

But note even companies in mission critical healthcare, like Philips, are adopting cloud, open source, and agile in their next-generation health management systems that integrate with their MRIs and CT scanners.

Re: Scrum is the new waterfall

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

"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." My employer (Pivotal) uses XP across the company as a way of building consistently high quality software products at a sustainable pace. We have something of a reputation for doing this over the past 20 years with Pivotal La…

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 unchanged. Which is often a requirement.

Agile is useful if you can always push the latest version to all users, as in web applications.

Post reply on HN