Planet SCM

Next Thursday, November 18th, there will be an event organised by Bits&Chips; about managing complex projects. Sure, it will be mostly in Dutch but it will be interesting anyway.

The challenge for software projects is to increase the productivity significantly; not by 10% or 50% but with 10 to 100 times or more. Will current process improvement initiatives achieve that? I doubt it. In my opinion, we need to reduce the size of projects instead of increasing it, we need to replace manual work and communication by machine work.

Have you ever tried to look at a very faint light, a star or so? And did discover that you can see it better by looking next to it?

In a science edition of the NRC (Dutch newspaper) I read an article about unconcious thinking. In the article it was claimed that the concious mind is only suitable for simple decision, like buying toothpaste. But when it comes to really significant decisions, the complexity is too large for the concious mind. The unconcious mind is able to think much quicker and take much more complex thinking patterns than the concious mind. Decisions like buying a car or a house, changing your job or starting your own company are best left to the unconcious mind.

According to the experiment, a number of people were asked to listen to a large amount of unrelated information. Two groups were asked questions about the information after half an hour to verify what they remembered of it. One group was left to memorize the information and the other group conducted a numbering game that required them to use their rational abilities. It appeared that the second group was able to answer more questions correctly than the first group.

I was amazed by it, but it concurs with my own way of learning. If I absorb an amount of information and go do something else that takes my mind off the subject (playing on the piano or even studying a piece, for example), it is much easier to remember and see all kind of relationships in what I learned than when I try to stay concentrated and focussed. Sleep on it!

Technorati tags: Mind, Unconcious, Thinking

In Dr Dobb's Agile Newsletter of July 2006, Scott Ambler writes about the "Green Shift". I was reminded of the article by Jason Yip.

The problem is that the project status "green shifted" as it rose through the various levels of management. The people on the ground were very clearly reporting a red project status, our project manager wanted to play it safe so reported yellow status, and his manager was more political yet and reported green status.

Green-shift is a form of information "erosion". When rocks erode under the influence of wind, rain, sand and dust, the sharp edges of the rocks disappear first. Next the shape of the rocks will change and finally the rock will crumble into pieces losing its original form entirely.

Erosion of information is a natural phenomena in communication. Every time a story is told, it is changed a bit. This way insignificant events may become spectacular (red-shift) and alarming reports may become uplifting (green-shift).

I like the solution that Scott proposes that by holding scrums the green-shift can be reduced. Three elements may play an important role in this. First, direct communication instead of passing the information over several layers. Less layers means less erosion or green-shift. Second, frequent communication reducing the delays. Less delays means less (time for) erosion. And thirdly, a scrum adds non-verbal communication that (written) reports are lacking. This improves the interpretation of the information, and interpretation is one of the sources of information erosion.

For many people Configuration Management is little more than controlling the versioned storage of work products, sometimes extended with Change Control which is little more than controlling change requests and problem reports. But both boil down to something like an sophisticated database with a sophisticated tool, sometimes not even sophisticated.

But the real added value of Configuration Management is that it helps manage and control the project. Let's have a look of a project in general first. In short every project is an enterprise, a journey, to establish a particular result of a particular quality, within the limits of particular resource constraints (typically money, time, people, technology, methodology, etcetera).

Every project starts with planning. Planning the result means expressing the results in items that will be delivered - if the project is executed according to the plan. Those items need to be identified (Configuration Identification), controlled (Configuration Control) and must be of a certain quality level expressed by a status (Configuration Status Accounting). So the first order planning of - the result of - a project already involves configuration management.
Secondly, these resulting items don't fall out of the sky; they need to be developed. So every item will require at least one task in the planning that produces the item. Some tasks may even product multiple items, that's OK. But every task needs input. So there we have a second order of configuration items.
Thirdly, these second order items need to be produced also, or they are inputs to the project from an external source. These can be requirement definitions, architectural definitions or even complete subsystem implementations from another project or a previous project.

Anyway, project planning strongly involves configuration planning, which is a responsibility of configuration management. In other words, configuration management is part of project management, at least during planning.

After the planning has been built up, which involves a lot of other things to be planned as well, the project is executed according to the plan. The tasks are being executed and the (planned) items are being produced as the result of the tasks. Some items may be produced iteratively, thus producing multiple versions of it. Anyway, these items (i.e. the versions) are stored in the CM system and status is assigned to indicate the progress of the item (how far is it "ready"? which is a quality attribute) and the maturity (how good is it? which also is a quality attribute). But controlling the versions and their status - and even the status of integrated items, which is a different thing than the status of the individual parts. This is all Configuration Management, which contributes to the Project Monitoring and Control of the project.

All I am saying is that the deliverable planning and tracking processes are both part of Configuration Management and of Project Management. That's why we should not consider CM in terms of the tools, databases, licensing issues, disk or network performance issues, branching issues, access control, etc. Those issues are not configuration management, but they are IT systems management issues. Configuration management is a project management discipline that is concerned with managing the physical work products of the project.