Scrum works fine when it's just programmers. Scrum and Agile become shackles when management gets involved and sees it as a status-checkup for their top-down view. The latter scenario seems to be 90% of situations, unfortunately.
Scrum is the new waterfall
81–90 of 183 posts
Re: Scrum is the new waterfall
#82Earlier quoted context omitted.
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 t…
Unfortunately, outside of a small percentage of companies, most software written today is just bad.
Re: Scrum is the new waterfall
#83Earlier 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…
"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 b…
You don’t decide to build a bridge out of a specific steel without testing in models which kind of steel is ideal for your case, or if you might have to change the shape of the bridge.
But in the moment that others will build projects depending on your implementation being stable – in the bridge example, this would be others building the pillars for the bridge or the bridge deck – you have to keep the implementation stable. (In software, this is usually third parties basing software on your interface)
Re: Scrum is the new waterfall
#84Earlier quoted context omitted.
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 t…
I really think you need to build a lot more software before you can make a claim like that. You're being fed lines from your professors.
The vast majority of software, period, is not backward compatible, has to be rewritten all the time, and costs billions to maintain, and is hard to maintain.
Agile vs. Waterfall is only one factor among many in such as discussion. The difference with Agile is in its ability to deal with uncertain requirements, something Waterfall cannot handle by its nature.
Re: Scrum is the new waterfall
#85Earlier quoted context omitted.
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'…
Third party services depending on you having a stable API, for example.
You can’t just break support for them, so what do you do in agile?
Re: Scrum is the new waterfall
#86Earlier quoted context omitted.
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 t…
"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." I really think you need to build a lot more software before you can make a claim like that. You're being fed lines from your professors. The vast majority of software, pe…
And this piece of software exists. Governmental projects interacting with lots of insurance companies, for example. Like the Elektronische Gesundheitskarte – a concept of giving every German an insurance card issued by the government, with all medical data stored in a cloud with insurances, doctors and pharmacies having access to it.
Before the software was even finished, PoS software was able to interact with the API and insurances had sent out millions of cards.
Breaking anything at that point costs millions.
EDIT: regarding your edit: Agile is far more suited for constantly changing environments, where you also can just break support for any third parties depending on your API. But obviously, that’s not really quality software when every software depending on yours has to be changed every few years.
Re: Scrum is the new waterfall
#87Earlier quoted context omitted.
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 c…
Re: Scrum is the new waterfall
#88Earlier quoted context omitted.
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 t…
Your response is selection bias. Every project that you've seen is a ball of technical debt. There is no argument to how documentation alleviates technical debt. If you document a poorly designed and scoped piece of software it doesn't make it any easier to change.
If the software was impossible to change and that change was a requirement then the code bases you were working with did not represent "working software"
The agile manifesto says, "working software over documentation." It does not say "working software and an absence of documentation."
The fact that you needed to add features is exactly the reason agile exists. If the creators had a complete feature plan in the beginning and faithfully executed it without deviation from the plan then there would be no need to ever add features and the quality of the code in terms of "changability" would be moot.
Re: Scrum is the new waterfall
#89I'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…
My favorite was being chided by a phd student teaching assistant that I needed to understand how things worked in industry if I wanted to pass. Problem was, I'd worked for multiple companies at that point and he'd worked at 0. What he was looking for (what it was exactly I don't recall) hadn't been my experience anywhere I'd worked.
Re: Scrum is the new waterfall
#90I 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%…