My observation is that Scrum/Agile/<your favorite SDLC methodology here> is just a proxy for team competency. If you have a team that is technically proficient at what they do, have reasonable time management skills, and are motivated and incentivized properly, it doesn't matter what SDLC they use and they'll figure out an efficient way to succeed. At the same time, if you have a rag-tag team of developers who don't know what they're doing all the time, it doesn't matter what SDLC they are using, they are going to fail. SDLC might give some guidelines for managers to feel safe but it all comes down to understanding the economics of the team and figuring out what works best for them.

I have a diferent perspective.

I work in a portuguese bank at almost 2 decades and now we use Scrum and Kanban.

For the sake of clarity when I talk about Scrum in "my bank" I use two epochs: - b.s. (before Scrum) - a.s. (after Scrum)

Before Scrum we work hard and we dos many things, but we didn't measure nothing so we didn't learn.

After Scrum, we work hard, we build, measure and learn.

We have performance indicators, we know where the botlenecks are, we know a team velocity and how many Functionalities IT deliver in racha month/year. We can compare the performance with other years. We can learn with our mistakes because we have data to prove it.

Scrum have disavantages, but in my humble opinion working without Scrum is a lot worse.

Yes, I have seen Scrum work well. The key is to recognize it is a tool for increasing team performance, team member autonomy, and increasing organizational transparency.

It is not a product management framework that should be used to manage inch/milestones and the like.

As soon as some sort of top-down control is (almost invariably) applied, it breaks Scrum. And most organizations want top-down oversight and control, not a high-performing team that may be resistant to organizational processes that negatively impact product development while satisfying other organizational needs (like LOC metrics or something else equally pointless).

Scrum is just empirical process control and improvement. The iterations aren't just to do the next thing on the backlog, but to improve the team's ability (and speed) to create working software that satisfies business needs.

The main reasons I have seen scrum fail are:

1) The organization implements a layer of management on top of Scrum that "won't effect it", but it does, because if you don't understand Scrum/agile, modifying it usually won't have the desired outcome.

2) Inexperienced Scrum Masters who act as a team leader, when their actual defined role is that servant coaches whose goals are to protect the process from interference and the team from organizational intrusion during sprints.

3) The transparency required for Scrum to operate reveals inefficiencies or actual malpractice at higher levels, and those levels are protected by management, creating a roadblock that cannot be passed.*

As you can tell, yes I have drunk the Kool-Aid, but I have seen Scrum (and other agile implementations) drastically improve performance and software quality, but you have to have buy-in and support from the highest levels to make it a success. When the process meets a roadblock that cannot be removed, it kind of kills the whole thing.

* Personally, I have seen it reveal:

- VPs who are actively preventing projects from succeeding (but who are protected by their level), - Rockstar (cowboy) coders whose poor development practices (no source control, no testing, code in production) negatively impact the rest of the software teams, but as they are the CEO's buddy, nothing can be done to address the behavior, - Database teams who successfully blame their errors on software development teams, because the Director of DB is a buddy of the President, so his word is taken over actual evidence

I've worked at three places that used Scrum (and am a certified Scrum master), and while it was pretty much a nightmare all around, I did actually see it work once, on a different team in a company I worked at.

I tried hard to find out why it worked for them and not for the other teams, but was never really able to figure it out.

Sad story. I belive that you need to be working side by side in a team to understand the dynamics in it. It's probably really hard to spot who or why a team works from the outside. All the right micro-optimizations decisions taken ...

No, I have not ever seen it work well. I was so frustrated by its prevalence in the industry that it was one of the main reasons why I decided to leave software development and work in cyber security / penetration testing instead.

I have since returned to software dev because the fact is I love coding and development but I try to minimise the time I spend working for companies by only working short term contracts while working on side projects inbetween jobs. If one of my side projects becomes successful and I end up hiring developers then there is no way in hell I will be forcing the horrorshow that is Scrum on them. Yes, yes I know "thats not real Scrum", but that doesn't change the day to day reality of working in teams that follow Scrum, or "Scrum".

I think this often comes down to why a team uses Scrum. Does the team actually see value in it and want to use it? Or are they told they have to use Scrum?

Generally it's the latter, and people are just forced to use it. However, I have made an honest effort to try and see the value in it, but the whole concept of trying to squeeze everything into artificial scheduling boundaries via sprints just feels very weird to me. Invariably projects just end up spilling over from sprint to sprint, because even if you manage to break things up into small enough chunks to do a meaningful piece of a project inside of a sprint, then you still end up with leftover time at the end...and then of course you're not going to sit around doing nothing, but rather you'll go ahead and get started on the next sprint's work in advance.

So the ultimate outcome is that you have to follow a certain specific set of prescribed meetings and rituals every X weeks when the current sprint ends or the next sprint is starting, but the actual work that's happening rarely seems to follow a schedule that has anything to do with the sprint cadence.

Is everyone onboard the train or are there people who are not going to support it?

Was what you did before working better?

What comes out of your retros?