Track change packages and their implementation
Track change package propagations
Distinguish change requests from change packages
Assign “everything” an owner
Use living documents
Track and protect baselines
Don’t get hung up on tools. Use automated techniques to do routine tasks. Make sure SCM practices employed in the technical domain bring immediate or realized value to the project. Determine if there is anything else that can be done with existing resources to make the SCM process easier and more transparent to the developer.
If you must use existing processes and procedures, then tailor out everything that does not apply or does not present any added value. Speaking of added value, take a close look at the processes you are currently required to follow. Do they make sense? Are they current and do they reflect today’s business and technical domains? Is every step absolutely necessary? Can you find anything that you could live without? After making these considerations, coordinate the proposed changes with the project manager and the team, make the appropriate changes to documented practices and procedures, and communicate those changes to the entire software development or content application group so they are aware of what has changed. You may have to do some serious negotiating with some team members and management before changing these practices, but it will be worth the effort, because without their buy-in, things will remain “business as usual.”
During the last two years, I did a lot of research looking for better, more efficient methods of implementing SCM. Most of this research involved reading articles and books on leaner or lighter software development methods. What I have discovered a number of software development sub-cultures that are using well documented “ lean and light ” techniques that appear to work well for them. There doesn’t seem to be a shortage of companies in need of more efficient and effective business solutions¾and most want these solutions cheap and right now. Enter “ Agile software development. ” Agile software development is driven by a profound manifesto that reads :
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan. .
That is, while there is value in the items on
the right, we value the items on the left more.”
So, how do the Agile attributes affect SCM? Can SCM activities be mapped to the Agile Software Development Manifesto? First of all, the notion or concept of “Agile SCM” is new and not well defined. Secondly, SCM is not very visible or even very meaningful to “Agilists." SCM is not really mentioned in any of the seven Agile methods. Agile software development concepts are relatively new, but much of their framework is based on time proven manufacturing methods. So, before we get into mapping SCM to Agile concepts, we need to understand that the “Agile SCM group” is more than likely going to consist of an individual responsible for the “control and integrity” domain. This person will also be a senior member of the software development team, perhaps the project architect, who participates in development activities, works directly (collaborates) with project management and other team members, and one who may share her domain with another (perhaps a junior) programmer. Let’s see how SCM fits into the Agile framework.
Individuals and interactions over processes and tools. The Agile SCM practitioner trains and mentors team members ( individuals and interactions ) on SCM practices and methods. Agile SCM practitioners seek more efficient