Being able to point at a common process or approach and say, “Yeah, we do something like that” is really important. If you point at a practice and say, “We do SCRUM” or “We do XP” I would be worried about how agile you really are.
A key to actually being Agile is figuring out what actually works for your team and adjusting your team’s practices to do more of what works, and less of what doesn’t. It’s unlikely that any documented practice fits your team perfectly.
I would argue that a successful Agile adoption is founded on two basic things:
Understand what your customers (the business and nearby teams) need from your team.
Meet frequently with your team to discuss how to better deliver on those needs
If you started with Waterfall, and added retrospectives and process change to the mix, you would become more Agile over time. You can skip to something like Scrum or Kanban that seem like a reasonable guess at a process that might work, but don’t stay locked into any “Text-Book” Agile too long. Put the retrospective at the heart of your Agile transformation.
DevOps Corollary: Put really good post-release and post-outage post-mortems at the heart of your adoption of DevOps. This space is new enough that nobody even claims to have all the answers. The driving question needs to be, “How do we deliver better?”