Brad Appleton is, in my opinion, one of the all-around smart guys in the CM space. His focus for the last few years has been on Agile CM, but his writings are applicable to anybody doing software development, for a very broad definition of software – most of what he writes is applicable to almost any kind of intellectual property. And recently Brad has been doing some blogging about books on various flavors of ‘trust. ‘

Trust, to me, is one of those core values for most CM specialists. The fact is that CM is a simple job. There are certain requirements, and once you meet them you get to go home. In that way it’s a lot like being a system administrator: is the system up, is everything working? Okay, go home. Now admittedly it can be pretty hard to meet some of those requirements. That’s why I didn’t say it was an easy job – just a simple one. But that’s where trust comes in. Because whether your shop is an agile shop or not, the CM guys are more affected by trust than any single other thing.

Let me repeat that: CM guys are more affected by trust than any single other thing.

I’m a CM consultant. I get called in by shops that either don’t have CM and want to build a team, or by shops that already HAVE a CM team but have experienced enough CM failures that they don’t trust them any more. Since most companies obtain headcount by calling up a body shop and ordering it by the pound (kilos for the EU, I guess), I don’t usually get called first for CM team setups. It’s usually only after there are some bodies on site, when it turns out that CM specialists that are great at keeping an existing system going don’t have so much experience in starting a new system up from scratch. So there’s usually some kind of mess on the floor when I show up.

What does that mean for you? Well, it means that if you see me at your shop, you should make sure your resume is up to date. (Sorry, but it’s true.) It also means that you can keep me, or somebody like me, from showing up if you concentrate on building trust with your customers.

Brad’s first blog post about trust was on Covey’s “The Speed of Trust,” and in that book there are five “rings of trust” outlined. The second and third rings, or types, are interpersonal trust and organizational trust. That’s where I live, and if you’re smart it’s where you spend time each day maintaining your relationships with your customers.

It’s a pretty simple set of questions, but it makes all the difference.

1. Do the people you interact with understand what you need from them, and understand how to deliver it?
2. Do they understand what services you can provide to them, and how to request them?
3. Are all of these things practicable?
4. Do they perceive you as doing what is needed, on time, and without unnecessary oversight?
5. Do they perceive you as requesting things that are objective, and consistent, and in keeping with your and their function?
6. Do they believe the estimates and the explanations you give them?

If you can answer yes to all of those, you’ll never work with me. That’s because your customers trust you. If you can’t – if your customers distrust you – then as the level of trust decreases, the likelihood of a “fixer” being called in for your team goes up. In the credit card business, your interest rate goes up. In the CM business, the level of interest in working with you goes down.

If you’re a CM manager for a military systems contractor, then you’ve got a CM plan. And you’ve got a set of prescribed deliverables. And if the developers – software, firmware, systems engineers, whatever – know how to deliver each release to you, and it’s an automated, mechanical, simple chore, then you’re halfway there. If your other customers – the clients, and the development team that need to roll back to an earlier release – can submit a request and quickly get some kind of link, or bundle, or set of typing instructions, then you’re all the way done.

If you’re a build guy, or a release guy, or a deployment guy for a software team – agile or not – then the activities might be different but the questions aren’t. Does the team know how to get you to do a build, or cut a release, or deploy a package? Are there any bogus hoops they have to jump through? Have you built any passive-aggressive walls, saying “we want the development team to do this thing which they really ought to trust us to do but they overrode us that one time and now we’re bitter and whiny and nobody loves us”? Can a developer quickly get to the codeface of some old branch from six months ago?

I guess the short form is this. Are you doing your job? Are you making it as easy as possible for your customers to ask you to do your job for them? Because in my experience – and I’ll admit my experiences are all negative – if you aren’t doing your job, or if you’re making your customers pay some kind of “tax” (time, whining, paperwork, hoop-jumping, sloth, inefficiency) then you’re going to lose trust. And once you lose trust, you’ll see a little bureaucracy get started. And when that doesn’t work (and it rarely does) you’ll get to meet me. I’ll be the guy “we brought in to help gets things caught up.”

This isn’t a threat, quite. Because I don’t know you. It’s a reflection of the world as I see it, because I’m like a specialist doctor – nobody makes an appointment with a gastroenterologist to talk about how healthy they are. In my case, nobody calls me up and says, “We’d like to pay you to fly out here and sit in a conference room and live in a hotel for two weeks so that we can tell you how smoothly our build and deployment works!” (Man, I would LOVE that.) But what I get instead is, “We need you to come and fix our build and deployment procedures. Our developers don’t trust the CM team, and we’ve had a couple of blown deployments in the last few months.”

So anyway, I guess the upshot of this blog post – and this is much too depressing to be a CM Journal article, so it’ll stay a blog post – is that you need to make sure your house is in order, trust-wise. Go read one or more of the books on Brad’s list. Because CM teams seem far more Boolean than development teams. Developers can say “It’ll be done soon,” while CM’ers have to say “it’s not done.” And saying “it’s not done” leads pretty directly to “you’re not hired.”

I’d like to think that I’m the guy for writing SCM tool reviews. I’ve been a vendor rep, so I know where a whole bunch of the bodies are buried. I am independent, so I don’t owe anybody anything. I have done the developer job, and the CM guy job, and the admin job, so I know what those guys care about. But I’m scared.

The fact is that there are a lot of details in any SCM tool. I spent two weeks reviewing SureMerge, which when you come right down to it is a glorified version of diff, for pete’s sake. Most SCM tools have some kind of diff utility built in as an afterthought. If it takes two weeks to do the afterthought, how many months would it take to cover the check-in command? When I wrote the case study that discussed the development of Longacre Deployment Management, I mentioned that the first-cut questionnaire we used for culling vendors contained about three hundred questions. Guess how many paragraphs that would translate to in a review.

One thing that seems obvious is that different vendors are at different points on the spectrum of object-version versus change-set based development. Some of them allow, or require, you to select which model you want. A bunch of them want to provide those functions, but call them something different and pretend that nobody else has them. Another thing is that the vendors, and even their customers, are at different levels with respect to integrating change tracking tools with version control. And with integrating requirements tools. And with integrating build tools. And deployment tools.

I’d like to have a fair measure. Some common set of activities that I could do for each tool. A benchmark, if you will, that allows the reader to hold two reviews up side-by-side and see the strengths of one tool versus another. (Ditto, weaknesses.) But there is the real risk that what challenges one tool will be a built in subfeature in a second level menu of a more advanced or more integrated tool. For instance, CVS doesn’t have any kind of change request tool integrated. There are some hacks. There are some other “products” that integrate CVS. (cvstrac, for one.) What to do? Accurev doesn’t have a CR tool, but they integrate with just about everything. MKS offers a separate CR tool, and makes it trivial to do change-set based development. Rational sells it as an add-on.

The point is, a “standard review” has the real risk of not mapping well to the product features. My SureMerge review was built around exploring the product, and deciding which features were worth mentioning to the readers. Some of them made it, others didn’t. A “custom review” runs the risk of spending a lot of time talking about worthless features because that is what is interesting about the particular tool. (I’ll mention here that a nice lady from PlasticSCM asked me to write a review of their 1.0 product. I declined for pretty much that reason—the product was too simple. Now they’re at version 2.0, and have a lot of new features. Surprise!)

Another point of concern is that some parts of reviewing a tool need other users involved. Access control, security, and privilege issues need multiple users. Too often, demo or review software has these features disabled or dumbed down. It’s hard to be in conflict with yourself. It’s hard to create any kind of log-jam with only one user. (And of course, it’s a considerable pain in the tuchus by yourself.)

So imagine a “standard” review of CVS: I try to create a set of change requests, and …

This sort of suggests that there maybe should be some kind of onion-peel review. The tool is what the tool is, and the reviewer peels away the standard layers until the tool starts to be relevant. But how much value does that even provide? If I’m writing a review of CVS, and the reader needs MKS Integrity or Telelogic Synergy, whose time is more wasted—mine or hers?

Bizarrely, then, the right first step seems to be to write a book (No, this isn’t a joke.) about SCM. Then match each tool against the book. But that’s crazy talk. The next best thing to writing a book, of course, is getting somebody else to write a book for me. There’s two ways to get there: pick on some standard text, or “web 2.0″ it. I can’t think of a useful “standard book,” so the web 2.0 approach doesn’t seem too bad. Perhaps the approach should be to create a wiki, fill it full of standard questions, and then encourage the users to answer them. Of course, most users aren’t very good writers, but isn’t that what wiki-gnomes are for? Of course, that puts me almost in competition with CM Crossroads, a position I don’t think I want to be in.

Maybe the right answer is a little of both. Create the wiki, then “edit up” when tasked to doing a particular review. Take the standard questions, and render them into useful text. Now I’m competing with Gartner. Joy!

If you’ve got some ideas, boy do I need ‘em.