When I first started, we operated on textbook Waterfall standards - I'd be handed an issue from my manager, I'd spend an unspecified amount of time trying to fix it or implement it, and repeat. I had no context about what my other colleagues were doing, or about the greater scope of the project. We had several projects going on at once, which frequently missed deadlines or changed scope halfway through. I might spend a day on an issue, or two weeks - there was no assessment of how complex an issue was. Due to the age of the codebase, various parts of it had no unit tests or documentation.
Some of my other colleagues proposed using Scrum to organise a new project they were working on. Issues were organised, broken down as small as possible, and progress was delivered in Sprints. They estimated their issues, estimated a delivery date for each phase, and met it. They also implemented unit tests and completed documentation for the code.
Over time this method was expanded out to all new projects, with my colleagues organised into teams who focused on one project at a time (while handling maintenance of the older system).
I've found that pairing Scrum with other modern development techniques like unit testing and MVC architecture has made the projects much more maintainable and has given the teams more investment in driving the projects.
We use three parts of Scrum - standups, weekly sizings, reviews. While retrospectives were important early on, mostly everyone is happy with the level of Scrum we practice. A key thing is to not let these meetings overrun - that seems to be everyone's main complaint about Scrum is not letting it distract from actual work, but using the time to better plan it out. My managers can see the progress of a project in rea-time as well, between reviews and looking at the team burn-down mid-Sprint. We can better track issues that people are struggling with on a day-to-day basis.
I've now found it a lot easier to deliver projects on time, and to better justify why delays occur because of the increased amount of planning. My team members are now better invested in the project and morale is much higher. I see Scrum as enabling picking up other good practices as well, but it's not worth doing if you're not also pairing it with these other techniques, or it's just a way for management to hold lots of meetings. It really requires a team-based focus, which is why I think a lot of lone wolf programmers bounce off it.