Making SCM Agile

When the notion of implementing software configuration management (SCM) on a project is considered, the first thing that usually comes to mind is a methodology that uses a generous amount of process and documentation.

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?

Who is responsible for project-level SCM activities and work products? Well, the SCM group, of course. Who or what is the SCM group? That’s a trick question, right?  Not really. The “SCM group” may be one person or a group of individuals responsible for performing SCM activities and producing SCM work products. The SCM group gets busy quickly when a new project gets underway. Immediate and typical SCM tasks involve strategic SCM planning and determining resources (people, tools, and equipment), training needs, establishment of multiple and/or multi-level libraries and repositories for the range of objects expected to be produced, determination and implementation of appropriate build and release processes, among others. If a SCM tool is available for project use, the SCM group has to make all worthwhile tool features available to the development team. If a SCM tool is not available, then the amount of project development preparation the SCM group has to do becomes staggering.

When should SCM be brought into a new project? Well, it depends on the organization’s understanding of the value that SCM brings to a software project – throughout its development lifecycle and beyond. However, if a SCM group is not established or identified at project initiation, then project risks increase significantly. Once a SCM group has been identified, established, and becomes part of the project’s software engineering activities, the SCM group must determine:

• 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.

The larger or more complex the project, the more SCM is going to be needed.  Larger projects usually benefit from being supported by an experienced and trained group of SCM practitioners due mostly to a more generous budget.  That is, larger projects are more likely to get experienced SCM professionals who have adequate SCM experience or training. Smaller projects are usually not as fortunate to have experienced and trained SCM practitioners on the project team, because smaller projects are inherently staffed with “essential” personnel only – and budgets are more often constrained or limited. For the most part, the SCM group is selected by the project manager – the person responsible for all project activities and work products, including SCM.  The selection of the SCM group for a small software project is typically tasked to one or more developers by the project manager, although some organizations have in-house SCM expertise and new projects are subsequently provided with adequate SCM personnel resources.

Organizations that want to increase their process capability have the option of using the Software Engineering Institute’s Capability Maturity Model for Software (CMM-SW) as a software engineering standard.  CMM Level 2 activities and work products requires a defined project-level SCM process in place that:

• 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

Such activities may be acceptable to a large project, but for a small software project, the implementation of all CMM requirements for SCM is clearly overkill. Do we want to implement a process-heavy, document-driven SCM process? Does the organization have the resources to support process-based SCM? The Software Engineering Institute recommends appropriate tailoring of the CMM for smaller projects. That is, the organization determines how much process will bring value to the project, and how much process can be trimmed or eliminated to avoid schedule and cost overruns. Specifically:

• 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?

What if the project team uses ad hoc methods to get things done?  Is product integrity still a major factor? What about quality? What safeguards and workflows can be used to support good SCM practices without slowing down development efforts?  If the software development group’s process capability is relatively immature and ad hoc, then product integrity and quality will suffer.  What are the alternatives to the process-heavy and document laden methodologies espoused on so many software projects? Are there more efficient ways for planning and implementing SCM?  Is there hope for the small software project?

As a former SCM practitioner for about 9 years who believed in defined processes, policies, procedures, and documentation, I realize now that the methods we used to “help” development teams actually got in their way. In spite of our good intentions, the SCM group was often a bottleneck. Our methods were arduous, slow, and error-prone, and were based on rigorous processes backed by extremely detailed procedures and verbose, out-of-date documentation. I typically supported teams of 20 to 50 developers, without the use of automated tools. Back then we worked long hours fixing problems that we had caused by “doing the right thing.”  Often, an SQA engineer worked with us to help locate and resolve problems. The software systems that were constructed were built on rigid and unforgiving timetables using a traditional waterfall approach, which meant that if there was even a minor hiccup encountered along the way, things came to a screeching halt and the customer held intense re-planning sessions with our senior management to resolve issues and negotiate funding and additional resources.

Today’s tools are very sophisticated and have the potential to bring tremendous value to software development efforts ¾ for a price. Unfortunately, some of these tools are affordable only to companies with sufficient capital to make such investments. And the tools, themselves, require experienced practitioners in their application and use. Also, keep in mind that SCM “best practices” touted by vendors require serious consideration before implementing because they may not fit well into your business domain and culture. Implement useful best practices that apply or work in your SCM domain. That is, establish and apply the processes that work “best” for you and your team. The entire list of best SCM practices that follows [3] may not apply to every domain, but should be considered as a guide to establish good overall SCM practices:

Workspaces (where developers build, test, and debug)

• 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

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 [4]:

“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.”

(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)

Agile SCM is:

• 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

WARNING, Agile SCM may cause:

• 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

So, when is there too much SCM? Through careful collaboration and prudent planning by the project manager, project team, and SCM practitioner(s), the amount of SCM management and control for configuration items and work products can be gauged. Too much process and the team gets bogged down in trying to support practices that may not be adding real value to building products. Too much documentation and the team shifts its focus on preparing needless or unnecessary documents instead of producing working software.

And isn’t producing working software what software projects are supposed to do?

References

[1]   Jim Highsmith, Agile Software Development Ecosystems, Addison Wesley Professional; 2002, ISBN: 0201760436

[2]   Carnegie Mellon University, Software Engineering Institute, The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley; 14^th printing, 2000, ISBN: 0201546647

[3]   Laura Wingerd, Christopher Seiwald, High-level Best Practices in Software Configuration Management, presented at the Eighth International Workshop on Software Configuration Management, Brussels, July 1998

[4]   Agile Alliance website, www.agilealliance.org/home

[5]    Kent Beck, eXtreme Programming eXplained: Embrace Change, Addison-Wesley; 2001, ISBN: 0201616406