In addition to holding common "Agile" values and principles, much of the theory and application behind Agile methods has its roots in the principles and techniques of Lean Production and the Theory of Constraints or TOC (including Critical Chain). These days, Six Sigma has fashioned a "merger" with Lean called (surprise) "Lean Six Sigma" (or just "Lean Sigma") that has paved the way for certain aspects of Six Sigma to "leak into" what it means for "CM" to be Agile.
Agile SCM is not CM-Lite!
The basic CM principles are the same. Some new principles/tenets are added to create new requirements, and a resulting new style to go with it in order to match projects having those additional requirements. There can even be a (more or less) common core set of practices, but the way they are instantiated and the additional practices and techniques and mind-set still create a different result. One size does not fit all kinds of projects. Just because a core set of principles may be the same doesn't mean everything else about it is.
To reiterate: Agile SCM takes nothing away from traditional SCM but seeks to achieve the same results in perhaps a slightly different manner while remaining true to the basic principles of SCM. So it builds upon traditional SCM and still contains the traditional SCM non-development activities of configuration planning, identification, control, status-accounting, audit & review, build & release management, and the corresponding process for managing those activities.
Agile SCM does however inject the agile mind-set (and some would say paradigm-shift) into the discipline of CM. With that, comes an emphasis on flow and throughput of the project value-stream, and operating in service to that and to those who create value. Sometimes this has led to the slogan, “Add nothing but value, remove nothing but waste!" when it comes to any form of process change or improvement in a Lean/Agile environment.
One way in which the mindset can manifest itself in SCM is in emphasizing flow more than discrete events (e.g., rigid baselines, and authorization/access controls), and treating the integrated "whole" as greater than the sum of its separately assembled parts. This can be difficult for many to adopt, particularly when it comes to practices like continuous integration and test-driven development using fine-grained tasks and many commits and integrations during the lifetime of the complete implementation of a requested feature, fix or enhancement.