The Need for Agility in SCM

• difference.
• Focus the SCM solution on the needs of the developer with the "team" goals of writing the right software, on time and on budget - if you do this well, you will improve team velocity and software quality.
• SCM is not merely an administration role - if you're managing SOFTWARE, the SCM Administrator must have a deep understanding of how software is developed as well as how to administer the SCM tools being used.

There are many other areas of SCM that deserve discussion, but these seem to receive the most resistance. Over the past couple of years, I've started working with some customers who were trying out the new "Agile" methods like Extreme Programming, Scrum, FDD, etc. To my amazement, these teams were demanding many of the SCM principles that I was pushing with other customers with only limited success. They were demanding fully automated builds, built in automated testing, documentation at a high level those things that are stable and let the build system and version management system document the details. I also notice that everyone working on an Agile project is a member of the development team focused on a common goal - to develop quality software that meets the needs of the customer on a timely basis.

I believe in the Agile movement and I'm encouraged with much of the success we're seeing as it becomes more mainstream. I believe that the SCM practices mentioned above will help ALL development teams produce higher quality software in shorter timeframes. Agile projects offer an opportunity to showcase these practices and demonstrate the values for all software projects. 

Brad Appleton - SCM "Anthropologist" and Agile Advocate

I began my software development career in 1987 as a part-time software tools developer to pay for my last year of college. Somehow it “stuck” because I’ve been doing some form of tool development ever since (particularly SCM tools), even when it wasn’t my primary job. I even worked for a commercial SCM tool vendor. I had aspirations of advancing the “state of the art” in SCM environments, but soon became frustrated with the vast gap between the “state of the art” and the “state of the practice.” I concluded I could do more good by helping advance the state of the practice to better utilize available tools.

Shortly after, I discovered software patterns and the patterns community with their combination of analysis and storytelling for disseminating recurring best practices. Unlike the “best practices” I was accustomed to seeing, patterns focused not just on the solution, but on the problem, and the context in which the solution made sense. For me, the problem's context and the forces were key to understanding why one person's “best practice” was often another's “worst nightmare” when improving the comfort and quality of one's work environment and processes.

I had previously amassed a wealth of knowledge about SCM tools and their implementation in both research and industry. Now I wanted to understand more about the rhyme and reason behind how to use them effectively. I spent over five years as an avid SCM “anthropologist”, excavating for patterns in the use of over a dozen different well-known SCM tools and their user communities over the course of several hundred projects. During that time I met Steve Berczuk, and collaborated with him on several papers as well as a book of SCM patterns. We examined the connection between software architecture, SCM, and communication structures and observed how patterns of interaction and coordination have a profound impact on both software architecture and SCM “architecture” (and vice-versa).

When development and SCM