Home 
CM Journal Articles A Bridge Too Far?
CM Journal Articles A Bridge Too Far?
|
Should SCM be a full-lifecycle support effort or a way station in the lifecycle? Off the cuff, the answer is easy but with some healthy retrospection, it becomes a bit more complicated. In this article we'll explore what it means to do SCM within application lifecycle management. Right off the bat, arguments for and against full lifecycle SCM generally center around whether it includes change control or just version control. Version control may be simple or complex. Running concurrent and parallel development groups in multiple locations is going to require solid controls and process. But that's not full lifecycle support. It's done within the development group. If we look at change control, we must then include the process surrounding Change Control Boards (CCBs), the communication mechanisms between functional areas of the project or organization, release management, and other points in the lifecycle where there is a transition between parties. If you follow the old 973 standard, SCM means Configuration Identification, Change Control, Status Accounting, and Audit. If not, then perhaps we need to look deeper. What are the activities or events inherent in change control? Requirements are created and approved. Designs are based on those requirements so it’s inherent that those requirements are controlled for changes lest others fall prey to wrong versions. Development is based on approved designs as are the test cases. Deciding which feature sets will be included in specific releases is also necessary. And all these are linked directly to version control and communication between groups. Who makes those decisions? When do they need to happen? What needs to happen in order for something to be ready for the next group to pick it up and run with it? It’s all configuration management at one level or another. So, if SCM commonly manages the tools for version control and defect tracking, is there a logical reason not to see this in a full lifecycle perspective? You might make arguments that functional areas get together and do their thing without us directly present. And that's true except that they are dependent on our tools for effective communication. Having a tester pick up the phone to communicate defects is a surefire way to see some of those defects make it to production. By the same token, having physical copies of requirements as your base will generally encourage the wrong feature set to become final product or at least waste testing time. At each of these junctions in a modern software shop we are using tools to make sure these mistakes don't happen. And some tools tend to bleed across functional area lines. Using a requirements management tool like DOORS allows developers to do impact analysis on changes while Test Director allows development or the PM to keep an eye on what defects are being identified. But neither of these tools, nor their functional area owners, are focused on the full lifecycle. Being able to integrate the tools of the various functional areas into a comprehensive system is where SCM really becomes the value for an organization. We are really the only link in the chain where you can see the flow from idea to production implementation. In most small to mid-size organizations, no other group has that capacity. In large organizations, process advisors and process teams are capable of providing the structure necessary to handle the complex deliverables. SCM may be structured to contain multiple levels. One subset may just do version control, while another supports the tools and a higher level structures the policies in conjunction with the process team. The goal is to set expectations between groups. Expectations mean metrics and good metrics define progress. X must be in a certain state before Y can take over and move it toward Z. To start fairly, the first question to be asked should be, "who is the most knowledgeable regarding change control to get it going?" Few of us work in the big shops where process advisors live so this question becomes more relevant to the rest of us. Maybe the SCM group contains real process geeks. But perhaps, like many organizations, it's comprised of partial/ex developers. You may have people who understand the software or know how to compile but are not hardcore when it comes to the high-level organizational thinking necessary for good change control. You may find individuals in the various functional areas that possess the knowledge we need to set up the level of controls that are right for your organization. There might be a dev lead or test manager with previous experience in a highly configured software shop. SQA is often a good source. Utilizing these people may be the best option for your company, even if it's not SCM writing the rules. What someone or a group needs to accomplish is to identify how changes will be offered, decided, and completed and then to set the expectations of each group in the tactical process of implementing those changes. SCM, though, must maintain a presence. As the keepers of the tools for version control and issue tracking, we need to thoroughly understand the process in order to replicate and enforce it within the tools. This brings us to the next question. The second question to be asked should then be, "Which person/group is impartial enough to coordinate change control ongoing?" Whether you know all the intricacies of a system is not particularly relevant at this junction. Each functional area in the lifecycle has its strong points and would inherently influence the process of change control to its own best interests. But outside of SCM, each has a vested interest in seeing particular changes moved through (or not). SCM does not care what the product ultimately is, or how well it works. It doesn't matter if a particular feature set makes it to production. We care that the software is properly created, controlled, certified for quality, and delivered appropriately. While we understand the overall need of the business to survive and thrive, we are not encumbered by the personal ownership of a feature set and are not upset if the Test group fails a given module. This unique perspective enables us to provide fair and uncompromised stewardship through the lifecycle. That objectiveness is necessary because it goes hand in hand with quality. Even if we just stick to our knitting, we find that the greatest value for organizations happens when the concepts of SCM are applied across the board. Inherently, we provide both tactical and strategic visibility into projects. Trying to force that functionality into a single step of the lifecycle short changes the organization and provides a disincentive to think beyond each team member’s functional area. SCM cannot be a way point. It must be the system of bridges between areas in order to be most effective and valuable. It’s not a bridge too far. It’s a bridge far enough. Randy Wagner is a Contributing Editor for CM Crossroads and VP of Technology Development with Taylor Bean & Whitaker in Ocala FL. His experience ranges from major financial institutions to multimedia multinationals to the Federal government. Working in small to large project efforts has given him a unique perspective on balancing the discipline of SCM and enterprise change management with the resources and willpower each organization brings to the table. You can reach Randy by email at randy.wagner@cmcrossroads.com.
Set as favorite
Bookmark
Email this
Hits: 5871 Trackback(0)Comments (0)
|
| Last Updated on Sunday, 05 August 2007 16:19 |
TrackBack URI for this entry
Subscribe to this comment's feed