Scrum is the new waterfall • Hacker News Board

Re: Scrum is the new waterfall

#51

Post by yexponential » Wed, Nov 11, 2015, 12:17 AM UTC

PythonicAlpha wrote: post #20

As I experienced Scrum in practice, it is said that people should be "empowered". In reality, something totally different is happening: People are not empowered, but the management just delegates the responsibilities for the project to the developers and lays back, assured that they just have to wait for the "agile fruits" to be reaped. They have done everything, they could do, now the "empowered" employees have to s…

This. 1000x. This is definitely one of the pitfalls of poorly implemented scrum. For bigger companies, scrum tends to be a decision by the higher ups and implemented by the lower ranks keeping middle management is disarray over their role in the change. Moreover as the author mentions agile is about people first, but followed by processes. If scrum teams don't have the power, or empowerment, to change the processes, to become more agile, to remove blockers/impediments, the team burns out / self destructs for the precise reason you mention about spending longer hours achieve the committed (not to mention the committed is affected by the deadlines which are manipulated by management/or worse, external stakeholders) in order to uphold their word/project. To me there is a flaw here.

I do believe scrum can be an effective tool for a few use cases, but people often underestimate the warning signs. "Scrum is easy to learn, but difficult to master." - https://www.scrumalliance.org/community/articles/2011/may/sc...

Re: Scrum is the new waterfall

#52

Post by braythwayt » Wed, Nov 11, 2015, 12:18 AM UTC

kuschku wrote: post #36

jdbernard wrote: post #33

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…

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 documentation to prove that the software works, you incorporate that documentation into your process.

It’s the same as emphasizing collaboration over contracts. I worked for a decade in consulting, I assure you there are contracts with clients even when you use Scrum. You don’t refuse to have any hard, contracted, binding commitments. It’s just that you prioritize collaborating with people over setting up solitudes that communicate by throwing contracts over a wall.

As for responding to change over following a plan, if you can set up an environment where there are no changes allowed to interfere with the plan, by all means ignore change and follow the plan.

But if you actually have changes that matter, you need to deal with them too. But that doesn’t mean don’t plan, or never follow any plan. It just means, respond to changes that matter.

For example... What if you discover that the security for a piece of software need to be updated. You’d respond to that, wouldn’t you? You wouldn’t push on to finish what was originally planned with your fingers in your ears?

These are guidelines. They’re motivating forces. You are supposed to do it in harmony with the hard requirements of your business and domain.

Re: Scrum is the new waterfall

#53

Post by matthewmacleod » Wed, Nov 11, 2015, 12:18 AM UTC

kuschku wrote: post #46

matthewmacleod wrote: post #38

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

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.

Re: Scrum is the new waterfall

#54

Post by rjspotter » Wed, Nov 11, 2015, 12:20 AM UTC

kuschku wrote: post #36

jdbernard wrote: post #33

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…

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

Re: Scrum is the new waterfall

#55

Post by kuschku » Wed, Nov 11, 2015, 12:20 AM UTC

matthewmacleod wrote: post #44

kuschku wrote: 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…

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 every problem separately.

Re: Scrum is the new waterfall

#56

Post by kuschku » Wed, Nov 11, 2015, 12:21 AM UTC

matthewmacleod wrote: post #53

kuschku wrote: post #46

Earlier quoted context omitted.

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

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.

Re: Scrum is the new waterfall

#57

Post by parasubvert » Wed, Nov 11, 2015, 12:23 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…

"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 Labs.

"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 option."

This is partial nonsense.

Firstly, unmodified waterfall was never an explicit software development methodology, it was an example used by Winston Royce in 1970 about how NOT to run a software project. http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...

You think Amazon delivers software in a waterfall? Amazon has dozens of teams building microservices in parallel with thousands of releases to production happening daily. http://joshuaseiden.com/blog/2013/12/amazon-deploys-to-produ...

I was the General Manager of Operations for a Class 1 railway, and know something about how railways systems were design and built. Control software for railway switches is written around once every 25 years, so yes, one can do that in a more deliberately planned manner. Financial and billing software for railways is mostly Mainframe or packaged (SAP or Oracle), so that too, was built in a waterfall, which was by no means a guarantor of quality in practice, with many problems being discovered only after deployment.

Yard management systems and equipment tracking can be built in an agile manner, though mostly were built in the 80s and 90s so only add-ons and additions are being built in this way. Much of the surrounding demand management, BI, order management, and forecasting systems are built (at worst) in an ad hoc manner or (at best) in an agile manner, because the level of change required is too high to warrant the lead times of a waterfall-planned approach.

The point is that most companies that develop new products do not do so in a waterfall manner, they do it in a manner that allows for continuous feedback, because they've learned that quality in the face of uncertain requirements requires such feedback.

"Even if the target is moving, agile is never able to provide quality."

The most polite thing I can say to this is, "citation needed".

Agile methods are an attempt to use Lean product development principles in the realm of software. I think you may want to learn more about them before drawing such conclusions.

Re: Scrum is the new waterfall

#58

Post by matthewmacleod » Wed, Nov 11, 2015, 12:23 AM UTC

kuschku wrote: post #43

matthewmacleod wrote: post #37

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.

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 (and need to do timing analyses) or with interactions between multiple different systems.

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

Re: Scrum is the new waterfall

#59

Post by rbanffy » Wed, Nov 11, 2015, 12:23 AM UTC

kuschku wrote: post #35

sopooneo wrote: post #31

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…

Never allow your school to interfere with your education.

> in reality, leads to everyone working on random things,

No. It's just that we acknowledge plans need to change and draw new plans. If we feel something need refactoring, we refactor. If it needs a complete rewrite, we do it. We can do it because we have tests for everything. The tests define what the parts do. They are part of the documentation, one you can run and be 100% sure it is correct. When we acknowledge something needs to be redone, we plan for it.

> If your software is working, but there is no documentation,

See above.

> to quote a professor

Judge the argument, not the person making it.

> Apache License on GitHub. Suddenly developers started caring about code quality

A GPLv3 variation could have been a smarter move, but yes. Having people able to look over your shoulder is a fairly decent quality driver. All my recent work is open source and, when I cut a corner, I always document the corner, why I cut it and when and how I will fix it.

Re: Scrum is the new waterfall

#60

Post by kuschku » Wed, Nov 11, 2015, 12:24 AM UTC

braythwayt wrote: post #52

kuschku wrote: 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…

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 critical projects, Documentation over software. The best software is nothing without documentation.

That’s the first point where I have to disagree with it.

In many other points, agile leads to teams just carrying the technical debt with them.