Very quick one. Joe and Billy, I think we're all in agreement. Hurrah!

One thing I do to avoid the CCB name over function issue is.... not use it (it's not a very good name and does imply in many people's minds a 'large bureaucratic body'). I define a Change Authority. This can be read as either a single person (as in 'he's the Authority on this matter') or a body (as in Port Authority). If that doesn't satisfy then describe a Change Approver and then the Change Approval Forum is a support group helping the change approver understand exactly what they are approving.

Yes, it's somewhat irritating to have to use 'safe' words, but better that than get embroiled in debating the merits of running a 'Board' because they're more focussed on the name than the function (I suspect that's Marc's problem).

"It's a technology, in the same way as druids are a technology to forsee the future and slaves a technology to build pyramids (although I read recently that pyramids may not have been built by slaves after all)."

Torturing the word 'technology' like that seems unnecessarily cruel. I'm generally more kind to my native tongue than to visit that much abuse upon it, but I guess, at a long stretch you can say a decision making entity is 'technology' (of course, that makes Parliament a 'technology' :blink: , and pretty much anything else you care to mention for that matter).

"The mere use of a CCB is a choice to make communications private, synchronous, volatile: discontinuous."

I have no idea what your notion of a CCB includes, but it seems to be the antithesis of everything I know about CCBs and their operation. CCBs, properly implemented, have always improved communication, made changes more visible, and made system configurations more stable.

CCBs make change more synchronous? Yes, when called, for but not necessarily. And 'discontinuous' (assuming you're not doing a Humpty-Dumpty again) I guess CCBs have the capacity to make the change process unnecessarily discontinuous, but, again, that's more a question of poor design and implementation than a fundamental property of CCBs.

"It is the choice of control against management."
This is a false dichotomy.

The next paragraph of your reply again reflects a misunderstanding about the nature of CCB operation. New technologies are certainly helping to make CCBs easier to run, but are far from making them unnecessary. Your insistence on referring to 'meetings' betrays a certain naivety about CCB operation.

"Making this choice defeats management. It implies delays, poor quality, politics, frustration of all sorts.
Wrong. Wrong. Wrong. Wrong. And wrong. (At least you're consistent.)

There are no reasons why a CCB should cause unnecessary delays, poor quality, politics (by which I assume you mean the CCB is used for political games?), or frustration of any sort. (Other than, once again, a badly designed or administered CCB.)

"Eventually, failure in the context of competition."
And, finally, wrong. What possible grounds do you have for this declaration?

The mere use of a CCB is a choice to make communications private, synchronous, volatile: discontinuous.

It is the choice of control against management.

It may have been a valid strategy in times when there was no possible tool support, and when the degree of complexity was low enough to be dealt with by people during a meeting, but neither of these two conditions hold anymore, at least in any software related industry (not exclusive).

Making this choice defeats management. It implies delays, poor quality, politics, frustration of all sorts.
Eventually, failure in the context of competition.

Marc

Marc: you are wrong on both points; there should be a CCB, it is neither an obsolete nor a counterproductive technology (it's a function, not a technology, for a start).

That said, it is unnecessary to have a [i]large[/i] or bureaucratic body acting as the CCB. What is important is that the [i]function[/i] of the CCB is performed; changes are evaluated and someone takes responsibility for approving the work necessary to effect that change.

I've discussed this with many people over the years and almost always there is a misapprehension about the CCB that it must be a group of people sitting in a room every Thursday morning debating over changes. Now, it may be that some CCB are like this (certainly in large organisations the operational CCB that decides on major changes to operational systems tends to be like this), but most CCB are much smaller, often operated on a 'needs' basis, and can consist of just one person (the Project Manager for example).

The size and formality of the CCB is entirely dependent on the potential impact of the changes it considers. An operational CCB considers changes that have direct and often significant business impact. A project CCB considers changes that directly impact the projects delivery, resources (and so may approve changes that affect the project and the CCB size and formality will be commensurate to the project's size and complexity).

I suspect that what you mean, when saying the CCB is unnecessary, is that developers should be allowed to make changes on their own cognisance. I often advocate that projects operate a system that allows developers to raise and assess their own changes, and approve their own changes if that assessment shows the change is a minor defect correction, for example. In other words, they act as their own CCB; evaluating the impact of a change and approving it if appropriate. Any changes that are approved this way are notified to the main project CCB (again, for smaller projects, often the just project manager) so that they are properly monitored and tracked (ensuring that developers are not abusing the change system and are remaining focussed on maintaining the forward momentum of the project.

This form of developer CCB is not appropriate to all organisations, nor is it appropriate to all teams. As with everything, you need to decide what is appropriate to your circumstances.

Returning to the original question, I hope you can see ssmfone that 'it depends' is the appropriate answer. It depends on where your CCB is operating and what the potential impact of changes it considers are likely to be. An operational CCB is a very different animal to a small project CCB.