In a recent CM Crossroads article on defining Agile SCM I included the quote from Charles Handy that I recently picked up on my travels through an airport:

Go to the theatre and look at the programme. Everyone connected with the performance is listed, no matter how small their contribution. People like to be recognised as individuals. The word "manager" is reserved for those in charge of things, not people, the stage manager and the lighting manager. The people who are in direct communication with the customer, the actors, are directed, not managed, by someone who actually leaves the scene once the project is under way. He or she trusts the cast to go it alone, and as often as not, they improve on the production once the director departs. Trust inspires. One more thing - at the end of each performance they receive an expression of appreciation from their audience, direct feedback from the people who matter. No waiting for the annual performance appraisal.

Charles Handy, Myself and Other More Important Matters, Arrow Books, 2007 - ISBN 9780099481881

This obviously applies to more than just the directing vs. managing debate (e.g. feedback/appreciation), but really hit home for me as an expression of what those of us in the Configuration Management arena need to be doing. We should be directing our colleagues and developers rather than managing them (although we can of course manage actual configurations as before!). We need to get out and about amongst our congregation of developers and others, and infect them with enthusiasm and skills for the delights and benefits of good CM.

There is a huge danger, which I come across fairly frequently, of sitting in your ivory tower wondering why developers aren't doing what you know is "the right thing". They haven't got the message, they aren't doing what they should, and management isn't helping you to beat them up with a big stick to force them into doing it. Sometimes it seems we are just on a hiding to nothing...

In CM we need to aspire to the director (servant-leader) mold - we provide a support service for people to get on with their jobs and we help them do it, but it is they that do (most of) it, not us. There is obviously some level at which CM is still responsible for certain things - in particular processes and systems, and for auditing to ensure things have been done correctly.

Thus I am more and more convinced that, particularly for Agile teams, CM should be the responsibility of everyone not just the CM person(s). This means that as CM professionals our job is:

• to sell the ideas, principles and tools of sound CM while supporting people in getting their jobs done and delivering value to the business (not just ticking CM boxes)
• to solve people's day-to-day issues through education and tool/automation support
• to show how it is easier to do "the right thing" than it is not to do it - a little discipline is worth a ton of lost time due to bugs introduced, or things suddenly not working
• to get out and about and work with developers, pairing with them and demonstrating good CM practice, discovering those little niggling things that cause lost time and productivity or pain and solving them
• to ensure that our own working practices are suitable role models (avoid "do as we do not as we say...")
• to focus on continuous process improvement - there is almost always something more we can do (but again focus on value)

There are many challenges, and in an Agile world, it is more about working with people to define just enough process to be useful, and not too much to get in the way. I was fascinated to hear a vendor representative complaining that some of their customer had developers who were downloading and using Subversion for their day to day work as opposed to using the corporate tool. I wondered what had happened to make the tool or the configured process so unfriendly as to force the developers down this path.