Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Journal Articles

Standard Performance

Written by Randy Wagner

Monday, 18 February 2008 08:42

Having worked in some organizations where standards were the exception, it's surprising how often people mistake the resulting pain for people problems. Here are some points to ponder when considering the root cause of problems that occur.

The following indicators often sprout from poor standards rather than bad people:

Unrecognized code dependencies cause failures in production releases
Errors that were fixed are re-introduced to production
QA successfully tests, but the code fails in production because environments differ
Right file/wrong version
Production release issues were encountered that had been warned of in emails and should have been avoided

When a mature organization has solid standards, it tends to permeate all the activities. Good standards with coding lend themselves to good testing standards and good release standards. It increases training efficacy and reduces rework and production errors. But when an organization is still in the early growth stage, it starts to trip over itself and often has difficulty comprehending where the difficulties are coming from.

Simply put, when an organization grows, communication begins to replace raw talent as the primary dietary intake. Developer Jane, who used to write, compile, and release, is now head of the development/server administration group. All the things she did herself, or with people sitting right beside her, are now done by a team in either multiple rooms or multiple cities/states/countries. And while everyone may have the organization's best interests at heart, they won't perform in a coordinated manner unless work is simplified and standardized.

Henry Ford understood the principles of good process and used it to create a giant that went unchallenged for decades. At every station, he ruthlessly winnowed process down to the minimums which resulted in both cheaper and higher quality vehicles, a combination hard to comprehend in today's marketplace.   When a worker knows what they are expecting to receive, knows what to do with it, and knows how he is expected to hand the work off to the next person, the process becomes an efficient assembly line. In the case of software development, there may be different methodologies employed and actors re-playing parts over and over until the work product has sufficient quality and functionality to move into production. But, it is still effectively a production line for code.

If your CM group is managing code collisions across different development groups, there is a higher probability you are seeing code dependency failures in production. Good process really pushes that effort back into the development side of the house. Not only can you nip issues sooner, but effectively, it keeps CM from being in the position of directing Dev resources. Your process should focus on who's accountable and where activities and checks should be happening.

When you are seeing errors popping back up in production after they were "put to bed", you are probably seeing a process issue related to how development works on the code. They may be working off code on their local machine instead of getting the most recent code fresh from the source code repository, or they are not coordinating their merges well. Some tools provide support for this type of process with views or integration streams (e.g. Clearcase) and I certainly encourage that type of controlled structure where possible. Dev should have a written Software Development Plan (SDP) that identifies tools and process to avoid these sorts of issues. Testing, Requirements and other groups that have similar needs should be writing these standards for their own departments. Especially in organizations where resources are pooled and billed-out to projects, it keeps training simple and allows resources to be re-allocated with less hassle.

The environmental issue that was mentioned points to how we track parallel efforts and environments. Has CM provided a change control database to help move system and environmental changes through the lifecycle? The activity itself is a project management function (or system admin function) but CM's central position as the communication hub gives us the ability to make tasks easier to track and complete for the other functional areas.

Whenever you are moving code, it's ideal to use an automated mechanism that reduces the chance for human error. But no matter whether it's manual or automated, we must define the output so we know what to expect. And even more, we need to know that the buildlist we started from is good. So what standards can you create that reinforce quality deliverables? Are they measurable? Were the input work elements verified before they were delivered to you? Who, or what, will verify that you have delivered what you are supposed to deliver after your actions are complete?

Probably the best thing you can possibly do to improve your standards is avoid email. Expected issues, resolutions, even comments about a release should be directly connected to the tracking mechanism. Everyone receives more email than they want to read and often it leaves an inbox straining to keep up.    Devise a standard issue tracking system where all related material can be reviewed at production release. Emails get lost in the jumble, deleted, and are completely out of sight, not to mention the prod release crew is probably seeing this item for the first time and has no personal history with it. The communication is absolutely core to good process and standardizing it allows for repeatable and quality releases.

In each of these scenarios, we frequently see individuals blamed for systemic issues. If we did the hiring well, we didn't hire dumb, lazy people. We hired smart, motivated, and quality minded human beings. And in todays "do more with fewer people" competitive environment, human beings simply cannot be expected to never fail. The more we can standardize processes and establish input, tasks, verifications, and outputs, the faster and more accurately we can deliver work products. The more standards we can use to measure ourselves against, the fewer mistakes will propagate through the lifecycle. It will be easier to train people when they know what mark they are trying to hit and they can be more easily re-allocated within shifting priorities.

Standards are very necessary. No elite company or team can operate without them. Yet, too often we ignore them for short-term gains and wind up in a pattern of declining quality while blaming individuals. I like to think of standards in terms of aviation. A plane can only fly so high and so fast. Having standards in our processes is like shifting weight off the airframe allowing it to fly higher and faster. People are like the aircraft. Every one has their own capacity but providing good, measurable standards allows us to lift the weight off them and let them work faster and more accurately.

Randy Wagner is a Contributing Editor for CM Crossroads and Senior Configuration Manager with EFD in Sunrise, 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 SR_71_98@yahoo.com

Set as favorite

Bookmark

Email this