There’s nothing new about this impression – SCM practitioners are often faced with resistance from management and developers who perceive SCM as a labor-intensive activity and cost driver.  For the most part, large software development projects or programs need a significant amount of SCM to ensure product integrity.  So why do so many companies impose a lot of process and documentation on small projects?  Do they really believe that all that process and documentation will bring value to the small project?  The reasons are simple – ignorance!  That is, there’s a significant lack of SCM understanding or know-how, and anything not understood (like benefits and value) is generally ignored.  How much SCM is necessary on a small software project to ensure integrity?  What is absolutely necessary and what is “nice to have?"  What can be done to make the SCM process more efficient?  These are questions asked frequently by management and practitioner alike, because they are the ones who must plan and implement SCM.  Reliable software (software integrity) means that customers will come back for more business.  How can SCM practices used in process-heavy methods be reduced or tailored without adverse risk to product?  Why can’t we just “pick and choose” the activities and processes that add value to our immediate business culture needs?  There are answers to all of these questions, but we need to know a few important things about a project before development begins.

How many activities are needed to adequately manage and control software work products?

• How many activities are needed to adequately manage and control software work products?
• What are the absolute “must have” SCM requirements (activities and work products)?
• How much tailoring of SCM activities and work products is necessary?

• The level of SCM support for the lifecycle methodology to be used

   

• Scheduling of software baselines and critical work products during each development lifecycle phase, and each release

   

• If the SCM budget and resources are adequate

   

• What must be built (the software product or application)

   

• The size or magnitude of the project

   

• All necessary SCM activities and work products (as agreed-to by the project manager and the customer)

   

• The significance of each need must be very clear, that is:

   

• The lifecycle method(s) should be sufficiently iterative to allow for collaborative prototyping, multiple builds, and frequent releases containing some significant and customer/user agreed upon functionality.

   

• Accommodating project schedules is critical in preparing for SCM activities to support the activities and work products for each phase of the project lifecycle.

   

• Knowing resource and budget limits will help the SCM group focus on critical and necessary tasks.

   

• Understanding scope of the software product or application will enable the SCM group to better determine the level of SCM support.

   

• The size of the project in terms of resources, architecture, features, and technologies gives SCM a better understanding of the scope of work that lies ahead.

   

• The SCM activities should be determined intelligently to avoid becoming a bottleneck – meaning that SCM work products should be timely, useful, and concise.

   

• Has a documented SCM policy
• Has an established software configuration control authority
• Provides a dedicated SCM group available to perform SCM duties
• Provides adequate resources and funding to perform SCM duties
• Provides an adequate amount of training for the SCM and software engineering groups
• Prepares SCM plans for all new projects
• Supports planning to establish a CM repository for software baselines
• Supports the identity of controlled work products
• Supports the use of change requests and problem reports for configuration items (CIs) according to a documented procedure
• Supports the creation and control of the release of products from the CM repository according to a documented procedure
• Tracks CI status according to a documented procedure
• Communicates SCM activities to the project team and management team
• Audits SCM products, activities, and processes
• Measures the status of SCM activities taken
• Verifies SCM activities through senior management reviews
• Verifies SCM activities through project management reviews
• Supports audits of the SCM activities and products by the software quality assurance group

• Which of the SCM common features will bring value-added process to a small project?
• Which documents should be produced and who will read them?
• What mandates the need for SCM products?
• Does senior management support SCM?
• Does project management support SCM?
• Is adequate funding available?
• What measurements should be used to determine adequate CMM compliance?

• Don’t share workspaces

• Don’t work outside of managed workspaces

• Don’t use Jell-O views

• Stay in sync with the codeline

• Check in products often

 Codelines (the canonical sets of source files)

• Give each codeline a policy

• Give each codeline an owner

• Establish a mainline

 Branches (variants of the codeline)

• Branch only when necessary

• Don’t “copy” when you really mean to “branch”

• Branch on incompatible policy

• Branch late

• Branch instead of freeze

 Change Propagation (getting changes from one codeline to another)

• Make original changes in the branch that has evolved the least since branching

• Propagate early and often

• Have the right person perform merges

 Builds (turning source files into software products)

• Source + tools = product

• Check in all original source

• Segregate built objects from original source

• Use common build tools

• Build often

• Keep build logs and build outputs

 Process (the rules for all of the above)

• 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

That is, while there is value in the items on
the right, we value the items on the left more.”

(http://www.agilemanifesto.org)

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 ways of controlling and managing project work products using learned skills.  Only when the needs of the project become more demanding and the tasks of controlling and managing project work products become noticeably less efficient, should automated tools be considered.

Working software over comprehensive documentation. The Agile project team is focused on Agile methods (e.g., pair programming, small releases, simple designs, refactoring, collective ownership, communications, commitment, etc.), and the suite of documents traditional teams are used to are not produced in favor of creating working software.  Thus, the Agile SCM group is likewise focused on simplified control and management mechanisms to ensure the integrity of the working software.

Customer collaboration over contract negotiation. The Agile SCM group and the customer work together closely to actively participate in the overall planning strategy (customer collaboration).

Responding to change over following a plan. The Agile SCM group participates in strategic project and technical domain planning.  In Agile software development, there may not be a CM plan. CM planning becomes an integral part of project planning, or the planning game (Kent Beck) [5], where continuous peer reviews, short iterations, and frequent project planning updates are the rule. The planning game is the boundary or the point of interaction between customers and developers (responding to change), specifying the responsibilities of both parties.

This is not the end of the story ¾ it’s really only the beginning. There are some very important things to remember about Agile SCM.

Agile SCM is not:

• A lightweight (or canned) version of traditional SCM approaches
• An approach that can be disassembled into pieces that can be applied piecemeal
• Measurable with irrelevant yardstick measurements
• A “silver bullet” (at least, not all the time)

• A process that requires a lot of work

   

• A finely tuned and congruent process

   

• Vastly different from traditional SCM defined approaches

   

• In terms of the CMM, Agile SCM is stable and repeatable only through Level 3

   

• Dramatic improvements in engineering build and code management practices

   

• Positive cultural changes brought about by collaborative teamwork

   

• Positive changes in management as the organization becomes fluid¾that is, teams become empowered and managers stop being bosses to become coaches, mentors, and facilitators

   

• Management changes as projects are tightly measured by return on investment¾that is, doing the right thing well, not just doing the right thing

   

• Ownership changes as business people become responsible for project ROI on an iterative, incremental basis, constantly balancing cost, functionality, date, and quality to produce the greatest benefit

   

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment