I do think think that there's a combo of simple techniques and rules of thumb, that, taken together, yield better results, with less ceremony, than Agile. And certainly far better than Waterfall, in the general case.
That combo (in my judgement) includes: iterative development, risk-driven prioritization, KISS/YAGNI, note-taking, scripted automation, CLI bias, FOSS, backups, version control and RDD (README-driven development). And several more, but these are among the biggest.
Because you don't necessarily need tests. You don't necessarily need pairs. You don't necessary need cards, or standup meetings. You don't need big upfront design. But you do need to produce working code. You should provide enough documentation to help you remember how things work and why, and bring new team members up to speed and/or project inheritors, and you ought to be flushing out assumptions or minimizing your biggest risks as early as you can, when there's still the most time to fix things, workaround, or abandon an approach entirely. These are rock solid, universal patterns I've seen over the decades. And they apply to small projects and large. Solo rockstars, small teams, large, etc. Independent of tech mix and software types.
And yes, ultimately the quality of people you have is the most important. They drive everything else: the choice of technology, tools, architecture, prioritization, morale, pace, resilience, etc.
That combo (in my judgement) includes: iterative development, risk-driven prioritization, KISS/YAGNI, note-taking, scripted automation, CLI bias, FOSS, backups, version control and RDD (README-driven development). And several more, but these are among the biggest.
Because you don't necessarily need tests. You don't necessarily need pairs. You don't necessary need cards, or standup meetings. You don't need big upfront design. But you do need to produce working code. You should provide enough documentation to help you remember how things work and why, and bring new team members up to speed and/or project inheritors, and you ought to be flushing out assumptions or minimizing your biggest risks as early as you can, when there's still the most time to fix things, workaround, or abandon an approach entirely. These are rock solid, universal patterns I've seen over the decades. And they apply to small projects and large. Solo rockstars, small teams, large, etc. Independent of tech mix and software types.
And yes, ultimately the quality of people you have is the most important. They drive everything else: the choice of technology, tools, architecture, prioritization, morale, pace, resilience, etc.