There seems to be many CVS users out there who desire to evolve their SCM solution to the next level. An SCM solution doesn't mean strictly a tool, but process and people as well. To migrate to the next level oftentimes means looking for a more integrated technology to support a more complete end-to-end process. It's also worth noting that a more complete end-to-end process doesn't mean a solution that slows down productivity - quite the contrary.

Over the past 8 months, we learned some important lessons about a couple of topic areas during our discussions of Agile SCM. This month we will cover these topics with the hope of clarifying the lessons and furthering discussion within our CM community. The topics are Communicating Agile SCM Concepts and Right-sizing documentation on your projects.

This article dives into more detail on the 6 most important SCM features required by an agile project. Some may say that agile SCM is about less discipline, but in actuality we find that it requires more discipline in the SCM solution.

This article is the first in a series for a column on CM Crossroads called Agile SCM. The articles are authored by Brad Appleton, Steve Berczuk and Steve Konieczka. This particular article introduces the column, who we each are and why we are interested in Agile SCM, and finally discusses where the column is expected to go in the future.

It seems sometimes like developers and SCM administrators communicate with a different vocabulary, causing difficulty in determining the "right" amount of SCM necessary for a given project. Often, the SCM administrator will take the position that all SCM is good. The developer will take the opposite perspective that SCM is bad - process for the sake of process. This article offers some common-ground to help determine the "right" amount of SCM for your project.

The primary goal of any IT department is to create the right software, on time and on budget with a high degree of quality. To accomplish this consistently, it is imperative that software releases contain well-known and documented change sets. This article discusses a clear way to articulate the problem as well as areas to focus resources that will result in measurable software quality improvements.