The Need for Agility in SCM

• between the teams to minimize the effects of geographic distance on collaboration?

The details of the system don't matter, and one would probably do it differently today, but the system we had worked well. It helped us to work together more effectively, and seems not to interfere with the way that we worked.

As time went on, I came across more organizations where the SCM and version management systems were either ineffective at managing versions, or they seemed to hamper the software development process. SCM policies were determined by fear of avoiding past mistakes rather than with the goal of helping the team to get work done more effectively. Where there was a release engineering group, release engineering and development seemed to be at odds. They seemed to have different goals: Development wanted to change code, release engineering wanted to minimize change. The idea that we were all on the same team never seemed to make itself manifest. SCM seemed to be an obstacle.

Of course, in the end, regardless of what the SCM infrastructure was, the teams eventually produced useful products. But it seemed as if developers spent a lot of time and energy working around SCM procedures rather than treating them as part of the process. Things would have been better if the SCM process and the development process interacted in a more effective way.

Given my early experiences in seeing how SCM can be helpful, I realized that SCM can be a tool for agility. Now is a good time for me to explain that I come at SCM from a developer's perspective. I learned what I know about how to apply SCM because it was sometimes lacking in my environment, and I knew that it would help. My initial reaction is to view SCM from the perspective of how it affects day-to-day development, and that means a 'version management' centric perspective. Even from that limited perspective, developers need to understand how SCM is an essential part of their toolkit, and SCM practitioners need to realize that they share a goal with developers: Producing quality software as effectively as possible. 

Steve Konieczka - SCM Consultant and Agility "Enabler"

The beginning of my career involved work with a large Big 6 consulting firm doing software development where I was exposed to many different approaches of SCM. Our success often hinged on the SCM solution employed. So when we started SCM Labs 5 years ago, we set out to do SCM with the needs of the developer in mind. Our methodology for SCM comes from the developers' needs first - and we found that managing the corporate assets and meeting many of the standards naturally followed.

There are several SCM practices that I have always believed provided significant team productivity and software quality improvements. Over the past 5 years, however, I've experienced resistance with many of these, until I started working with Agile development teams. Some of these practices include:

• Fully automated builds with automated periodic integration and build processes.
• Automate as much testing as appropriate allowing as much regression testing as possible - then build this testing into your build process so that you can test as part of building software.
• Don't get bogged down on documenting the Configuration Items "outside" of the SCM solution - as soon as you're done documenting, you're out of date. Your SCM solution should keep that information tied to your releases and readily available.
• The SCM solution must implement "frictionless change" for the project - not roadblocks to change. SCM is not about "Controlling" change but keeping track of change. There's a