responsibilities are segregated such that development essentially “throws it over the wall” to SCM, the two groups often take on an adversarial relationship: Many developers perceive SCM to be overly formal, rigid, and bureaucratic. At the same time, many software configuration managers and SQA professionals often perceive developers as undisciplined or ignorant of SCM concerns, constantly compromising product quality or integrity in the name of schedule or development speed.
The truth is that both sides are both right and wrong! The real problem is that they are on two different sides instead of on the same side. The integration/build “wall” is a barrier to effective communication and collaboration between developers and SCM. Something must be done to break the cycle and bring both sides together to tear down the wall! SCM is a “whole team” responsibility that must be part of regular day-to-day activities.
Software development is not some assembly-line process but is truly a knowledge creating activity that inseparably requires exploration and discovery throughout the entire lifecycle (not just in the early phases). What this ultimately means is: Processes don’t develop software. People do! And while SCM process needs to help product quality and integrity, it is people that are at the center of creating software. So the process and the tools must first and foremost serve the people who practice and wield them (not the other way around).
These same conclusions are shared by agile development methods, which both myself and Steve had already been following for several years. Our combined interest in SCM for agile development is what led us to cross paths with Steve Konieczka (both on the scm-patterns mailing list and on CM Crossroads ).
What you can expect from us So united in purpose forged by our different but common experiences, the three of us (a developer interested in SCM, and two SCM developers) have banded together on a common mission to initiate discussion on topics that we believe will drive to higher quality software that meets the needs of our customers on a more timely basis. This CM Crossroads community is the place on the web for all of us to come together and discuss these topics and change our industry for the better.
The basic tenets representing our collaboration include:
- Agile SCM process must serve its practitioners and not vice-versa
- Agile SCM should break down traditional walls between SCM and developers to bring the whole team working together to accomplish our goals
- Agile SCM should be about responding to change rather than preventing change
- Agile SCM should track and coordinate development rather than trying to control developers
- Agile SCM should strive to be transparent and “frictionless”, automating as much as possible
In the coming months, we plan on publishing some controversial concepts that we hope will spawn productive discussion. Please participate in this discussion because we will all be better for it. Some topics we plan to introduce in the coming months include:
- SCM and Team Velocity - explaining the details of how SCM can provide enhanced team velocity
- Multi-Level Continuous Integration
- Pitfalls (anti-patterns) and how to diagnose, recover/remedy and prevent
What we hope to get from you We want your feedback and ideas about SCM and agility and growing and fostering a community to support agile SCM. We want to hear about your experiences, your concerns, your war stories and lessons learned, what has worked for you and what hasn't, and what vexes you most about reconciling SCM and agility and getting SCM and developers working together instead of against each other.
See you all next month!
References
- Agile Configuration Management







