Scrum is the new waterfall • Hacker News Board

Re: Scrum is the new waterfall

#71

Post by JoshTriplett » Wed, Nov 11, 2015, 12:34 AM UTC

wadetandy wrote: post #9

JoshTriplett wrote: post #3

Earlier quoted context omitted.

Having worked on a team using Scrum, I agree with this: it's pretty much the least process you can have while still fairly accurately predicting when work will get done and when any given feature will show up in the product. But it can be done well or badly: the team I worked on rigorously adhered to the process, and only cautiously diverged from it after careful consideration. Scrum done badly will rapidly become mi…

I feel like every time I complain about scrum and my frustrations with it to people who believe in it, the response is always "well you just don't understand scrum," or, "you're just not doing scrum correctly." If the process is really as good as it is supposed to be and espoused to be by scrum evangelists (including many of the coaches my companies have hired to help us implement it), then I wonder why it's so hard…

> If the process is really as good as it is supposed to be and espoused to be by scrum evangelists (including many of the coaches my companies have hired to help us implement it), then I wonder why it's so hard to do correctly.

I'm quite skeptical of "agile coaches" and similar.

But in general, I'd suggest that it's easy to break by either swapping out or eliminating one of the defined roles, having someone unsuitable for those roles doing them (e.g. a manager or program manager serving as "scrum master", which instantly turns scrum into micromanagement), having an excessive number of mid-sprint changes (if changing a sprint's work mid-sprint happens every other sprint, something is very wrong), or not having any acceptance from the broader organization for getting work done at a regular cadence without constant "emergency interrupts".

You should not be spending any significant fraction of your time in planning meetings; those occur once a sprint at most, and the sprint-planning portion should mostly consist of quickly doublechecking priorities and grabbing the top stories by priority. The other significant effort lies in breaking down and "sizing" stories (which is the job of the development team, not the person providing requirements).

I do agree that Kanban can work as well; it just doesn't (in my opinion) have good predictive power for when work will get done. (On the other hand, some of our teams ended up switching to Kanban because Scrum doesn't work at all with a distributed team.)

Re: Scrum is the new waterfall

#72

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

parasubvert wrote: post #69

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

And I can tell you that even some cloud software, like the Elektronische Gesundheitskarte was developed with Waterfall.

Often you have to design software interacting with dozens of other entities, all who are going to write software interacting with your system.

And your system is supposed to be able to run for years or decades with minimal maintenance.

Agile is far more suited for web apps, or small mobile apps, which can be constantly updated.

Re: Scrum is the new waterfall

#73

Post by anon4 » Wed, Nov 11, 2015, 12:36 AM UTC

plet wrote: post #21

Whats wrong with waterfall? Surely mis-using waterfall was the culprit. I'm guessing same goes for Scrum. I've never followed true scrum so my opinion might be jaded however the devil generally lies in the implementation of the process. You cannot fit the same tire on a truck and a kid's tricycle, same way you cannot fit the same process for all development cycle. If you team needs clear direction and everything well…

Waterfall is literally a strawman methodology made up to illustrate the worst possible way to build software (short of having a million monkeys trying random programs), in order to serve as contrast to a way that actually works.

Re: Scrum is the new waterfall

#74

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

"Your software is not working if it doesn’t exactly match its documentation."

Not true. Documentation is not always updated. And many times, if not every time, the requirements documents the clients give are often flat out wrong. So you could build the software to the requirements, and end up with something that doesn't meet the client's needs.

"Documentation and Code Quality are some of the most important features."

However, these take a backseat to working software.

Re: Scrum is the new waterfall

#75

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

rbanffy wrote: post #59

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

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…

I added in the first comment my definition of quality.

And in projects like "ISS heating control", or "railway control system", or "electronical ID card for 82 million people", you want a software that is backwards compatible so third parties interacting with you will never have to rewrite your software, you want a software that runs with minimal maintenance, but is easy to extends, etc.

And Agile is ill suited for that. Agile is well suited for cases where no one ever depends on a your software providing a specific interface and where your target moves quickly and where you can ensure everyone always runs the latest version. In other words, small applications and web apps.

Re: Scrum is the new waterfall

#76

Post by parasubvert » Wed, Nov 11, 2015, 12:41 AM UTC

kuschku wrote: post #70

parasubvert wrote: post #57

Earlier quoted context omitted.

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

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

I can guarantee you that 90% of the code in the Positive Train Control systems (the first real "new" control/sensor system in freight in decades) were not written with this methodology.

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

"Almost never" a requirement, in my experience. And... centuries? Really?

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

Yes, or you know, mobile applications, or sensor network applications, or... basically pretty much most software that isn't in highly constrained environments. The revenue of the former is in the trillions; in the latter is the billions.

Re: Scrum is the new waterfall

#77

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

s73v3r wrote: post #74

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…

"Your software is not working if it doesn’t exactly match its documentation." Not true. Documentation is not always updated. And many times, if not every time, the requirements documents the clients give are often flat out wrong. So you could build the software to the requirements, and end up with something that doesn't meet the client's needs. "Documentation and Code Quality are some of the most important features."…

Your software is not working if all the third party services that depend on the API you provide are broken because you changed your API, or because your documentation is wrong.

You can work without documentation or without stable implementations if you control all the endpoints and ensure they always have the latest version (like mobile apps, web apps, etc). But if you can’t, you have to remember that every API version you’ll ever provide will have software using it, and you won’t be able to EOL the support for that version.

Re: Scrum is the new waterfall

#78

Post by jdbernard » Wed, Nov 11, 2015, 12:42 AM UTC

kuschku wrote: post #55

matthewmacleod wrote: post #44

Earlier quoted context omitted.

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

I'm very curious, what is your definition of waterfall?

Re: Scrum is the new waterfall

#79

Post by darkxanthos » Wed, Nov 11, 2015, 12:42 AM UTC

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…

This. It is so important to separate the practices associated with Agile apart from Agile. One practice I use a ton is retrospectives and really it's useful just as a way of codifying how much and how to experiment with and change team process.

Re: Scrum is the new waterfall

#80

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

kuschku wrote: post #67

matthewmacleod wrote: post #63

Earlier quoted context omitted.

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?

Are you just telling me that waterfall is also agile?

No, I'm obviously not communicating effectively.

Documentation is a deliverable component of a software system. As a result, it can be tracked and managed just like any other deliverable component.

In any real software system, the initial documentation will not reflect the finished system. That's inevitable – it's why we have errata. The difference between 'agile' and 'waterfall' in this case will be whether those changes to documentation are delivered at the end of development, or as they are required by changes to other parts of the system.