The software process stuff I've found most valuable is really the XP/Joel-Test stuff, not the Scrum stuff:
· nightly builds or continuous integration;
· pair programming or code review;
· automated builds;
· comprehensive test suites or test-first programming;
· fixing bugs before adding features;
· source code version tracking software;
· keeping a list of bugs and planned features instead of not keeping one;
· prioritizing planned features instead of not prioritizing them;
· merciless refactoring to keep the design simple;
· DRY, as a criterion for what "simple" means;
· "YAGNI" (not writing code to provide functionality that I'm not implementing right now);
· a sustainable pace (no death marches);
· exploratory "spikes" to explore unknown features;
· taking regular breaks;
· informal usability tests with prototypes;
· standup meetings;
· frequent releases;
· quiet working conditions; and
· retrospectives.
I'd add, though these usually go without saying these days:
· high-level languages;
· interactive development environments, as opposed to the batch-mode approach where you submit a batch job and get back your program output an hour or a week later;
· enough testing hardware that you never have to wait for a testing machine to become available in order to get your work done;
· using available software libraries instead of not using them.
I'm pretty confident that each and every one of these helps me build better software faster, though a few of them may vary somewhat depending on circumstances—I know a guy who can concentrate to write code better in a noisy café than in a private office, frequent releases are at best minimally useful for pacemaker firmware, and you couldn't have written qmail using existing libraries.
Also, though, I'm guessing that the old codebases you're looking at with simple spreadsheets for bug lists practiced "working software over comprehensive documentation", "customer collaboration over contract negotiation", "responding to change over following a plan", and especially "individuals and interactions over processes and tools". And those are the core aspects of agile development (though not the Fake Agile we so often see).
Some of these are things earlier generations of programmers could only rarely do. If you're working at a company that values processes and tools over individuals and interactions, there's not that much you can do to fix that if you couldn't start your own company; https://news.ycombinator.com/item?id=28670326 suggests one reason this is so widespread. Similarly for fixing bugs before adding features, using an interactive computer, having adequate testing hardware, and having quiet working conditions. Source control systems, automated builds, and automated test suites provided substantial benefits to teams that adopted them, but many didn't. That doesn't mean they weren't valuable at the time, just that many people did without.
By contrast, I'm less convinced of the value of private offices, written spec documents, schedules, dedicated low-paid testers, scrum masters, planning poker, splitting and merging product backlog items, quantitative task estimation, and even coding interviews.