If making mistakes helps us to learn then I have really learned a lot over my 20+ years in IT. By now a solid chunk of my career has been spent playing a hands-on role working in large scale Software Process Improvement with an emphasis on software testing, Software Quality Management and especially Software Configuration and Release Management. When I write I often feel that my readers would run away if they knew how many really bad mistakes that I have made in my career. Frankly, I have failed or at achieved less than acceptable success in many of the positions that I have held. It's one of the reasons that I approach my work with confidence. I have learned the hard way, what works and what doesn't. I often tell people that I don't really have any good ideas myself. I just steal what I have learned works and share these best practices with others. Please read on if you'd like to share some ideas on what CM best practices work and which ones I wish that I could have avoided!!!

It’s Not Just the Process…

You can define the best process model in the world and that doesn’t mean that it will fly. There are times when I have myself frustrated and alienated from my colleagues who preach software process improvement. Many of them whined about the company’s refusal to “accept change” and to be open to defining a better “process.” Many of these self-appointed experts had not even read the Software Process Improvement (SPI) literature and were unable to discuss the lessons learned from other Process Improvement experts. They could define the levels of the CMM and proudly announce that our company was at level “0”. But if you asked them to describe how to actually implement a KPA from the CMM or effectively use the ISO 9000-3 guidelines they were lost. Sadly other colleagues who did know the SPI literature were just as ineffective because they lacked the basic interpersonal skills to sell their ideas in a way that was in alignment with the organization’s goals and objectives.

I am not proud of the times when I knew what had to be done and I demanded that the organization do things my way because “it was the best process.” I know that sometimes I have done a poor job of “selling” my ideas in a creative and flexible way. Leadership does mean defining goals and clearing away barriers to change. Sometimes I have forgotten the technique in Judo of holding your opponent when you throw him (to break his fall!). Sometimes I had great ideas about the process and I forgot to consider the people who would have to live with the process on a day to day basis. This is pretty ironic for professional with a graduate degree in Psychology!

My Roots in Industrial Psychology

Right after I finished my BS in Computer Science (from Hofstra) I began graduate studies in Industrial Psychology (at NYU). I was consumed by the importance at not only looking at computer programming, but also at the way in which computer programmers did their work. Back then we called this work Productivity Support or Quality Improvement.  Winslow Taylor’s time and motion studies and Quality guru’s including Juran, Crosby and of course Deming were being ignored by American Industry. That’s one reason why I drive a Japanese car today. I knew that I was different from most people interested in QM because I was hands-on. When no one wanted to hear about Process Improvement I was perfectly happy (sometimes happier!) to build Unix kernels. I could participate in the software development process and command some respect from other developers with my technical skills.

Technology

One thing that I know that I got right was an obsession with developing strong technical hands-on skills. I could knock down a house with all of my technical books (I have worn our a few bookcases!). I have also had to buy more than one copy of book because I wore it out from use and wear/tear in my briefcase. Being hands-on is extremely valuable for CM and SPI professionals. Reading , studying and learning from others is a core competency that is as important as breathing to a technology professional. I have known good people who were not technology experts, but I do think that technical knowledge is an advantage that should be encouraged. We need to raise the bar on our technology training and expertise including those of us involved with large software process improvement.  Implementing SPI including better CM is much easier to do if you have the technical expertise to make it happen.  Technical glitches and problems can sabotage the best of SPI initiatives including implementing good CM solutions.

Process From the Bottom Up and Top Down

We used to say that process improvement had to start from the top (Senior Management) and work it’s way down (showing Senior Management “buy-in”). I think that is nonsense. Most initiatives started that way have no real value to the organization. I like to start small and make a particular group successful. I use that “win” to share ideas with the next group. I “run for Mayor” meaning that I get the development managers to see that I have something to offer and that I can make them successful. Once we are moving forward then I can ask senior management for their blessing to set corporate standards. At my current company we started with an edict that stated that all source code had to be secured. It was two years later that we standardized on a particular CM tool. Now we have a well defined release management process with well defined goals, standards and best practices. We’ve left some flexibility for groups to customize their process too. For example, CM plans are required, but we let each team define their naming conventions. We do give them a suggested naming convention, which most of them follow anyway.

People, Process and Technology

The lesson learned is that it takes an equal emphasis of considering people issues, well defined process and strong technology that results in successful Software Process Improvement. There is no possible way of doing this type of work without considering all three! We have learned the hard way SPI starts with considering the essential People issues, defining clear and useable processes and basing them upon solid technology. CM practitioners would do well to consider all three core areas as they develop their careers and provide value to their respective organizations.

Your Turn!

What lessons have you learned? Please write to me and share your thoughts and observations. I can include them in an upcoming article or you can post them yourself on one of our forums!!

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment