When I started out as a software developer I worked with a team of people who taught me that how we do things and why we do things as developers is as important as what we do. In other words: process isn't only the concern of senior developers. Everyone should care about finding ways to work better. Of course, the more influence you have over the team, the more you should care, since you'll have a bigger impact on the bottom line, but there are things that everyone can do to make their own work better and perhaps lead by influence.
Perhaps only a few should thing globally. Everyone should act locally. For example, any developer should be able to add tests for their code, independent of the team's global policy.
Goals and Intentions of the SCM Pattern Language
Perhaps the common definition of SCM patterns is that given in the book Software Configuration Management Patterns. A pattern language guides you along the process of building a thing, the SCM pattern language is not a guide to building every SCM process.
I could argue that most teams should be more agile than they are now, and could be so without sacrificing anything. Many restrictive (or non-agile) processes seem to have their origins in lack of trust, or an unreasonable fear of risk, rather than reasonable business goals. You are the one who best understands what your team is doing now and how it needs to improve.
The Role of Tools
The first question I get about SCM is often "What tool should I use?" Like all things, tools influence the way that you work. If you have a tool that makes something easy you may do something one way. Without that tool another approach may be almost as good. My advice, which is not often well received, is to understand what your work process is, what you want it to be, what your constraints are, and then pick a tool that supports them. Then you can think about whether you should use different tools.
The pattern language in Software Configuration Management Patterns does not care about tools beyond having some sort of version control system and some sort of build process tool. Of course, some tools make implementing some patterns more transparent than other tools do.
Applying the SCM Pattern Language for Process Improvement
A frequent complaint is that teams spend too much time stabilizing their codeline before releases, resulting in developers idling while the team integrates (and delays that cascade into subsequent releases). One approach to resolving this situation is creating a release branch and dividing the team's effort into stabilization and new release activity. This does not always work as expected if the release branch takes a long time to reach release quality. Time spent waiting for the release to be ready is replaced by time spent on merging release line fixes into the main line. The SCM Pattern Language provides a map to making resolving some of these issues.
A patterns approach would analyze how the problems relate and provide solutions that build upon each other. If your team has frequent releases you would attempt to focus most of your work on a single active development line, which would have a codeline policy that allows for frequent check-ins, but only after they run a suite of smoke tests and unit tests in their private workspaces. Developers will also be expected to do private system builds to provide added assurance that their check-in will not break the build. Later on an Integration Build will build everything, and perform extensive regression tests. By the time you are ready to start a release line, the code should be fairly stable, and you should not need to perform complicated merges between codelines.
While having a release line (applying a single pattern) relieved some pain, applying the Release Line pattern in context gave you a greater benefit.