Did you forget your: Username / Password ?

Microsoft

TechWell

Home

From the Editor

It's the process

Written by Bob Aiello

plush stuffed animals

This is my first post in my new position as Editor-in-Chief of CM Crossroads and I would like to start by telling you a little bit about my background and the way that I approach my work. Most of my career has been dedicated to helping organizations solve problems that impact their productivity and profitability. I have always worked as a full-time employee and actively participate as a hands-on member of the technical team. That means that I am usually the admin support for the source code management tools (e.g. ClearCase/Multisite), build and release the code and (when I am really having fun) get to build the Unix machines and actively participate in the technical support of the key development, qa and production systems. Most "process improvement" professionals do not attempt to be hands-on. I try to stay technical, in part, because I love having a hands-on role so much. It also keeps me honest and only implementing processes that I am willing to live with myself. By staying technical, I get to "walk the walk" instead of just "talking the talk."

The truth is that I am not as strong technically as a developer who writes code full-time and my expertise as a process engineer is more valuable to the organization than my prowess as a build engineer or perl script writer. I have had people who worked for me who could code scripts or solve maven/ant problems a lot faster than I ever could (or ever will). But at the end of the day, I can always come up with a repeatable process that even a trained monkey can follow and my process methodologies always result in reliable and repeatable build and deployment of application releases. If developers follow my techniques, than any release in production is fully traceable and the source is guaranteed to be safely under lock and key in my secure source code repository - which I monitor constantly.

This doesn't happen by accident and I didn't think up all the good ideas by myself. I have been sharing my views and experience with CM for a long time. Over the years, I have learned a lot and I hope that you will join me as we look at what works - and what doesn't - in large global organizations that depend upon successful Application Lifecycle Management. More importantly, we need to make sure that our processes are actually reasonable and that developers are willing to follow them and improve the quality of their development effort.

When the process is broken

There are lot of very smart technology professionals who cannot get a release out the door reliably each and every time. I have seen contracts and budgets on the edge of disaster because mistakes led senior management to question and doubt the viability of a project. Development teams that keep making mistakes loose credibility quickly, no matter how strong their technical expertise or robust their underlying technology. In these situations, it is often the process (release management process) that is broken.

Someone has to join the team and figure out exactly what went wrong and what has to change in order to fix the process. This is the essence of software process improvement. You always need to start with a clear view of the goals. Some are easy to identify and exist in every project. For example, if the release is in production, you must be able to identify the exact versions of the source code that went into the release and be able to make a 2 line change without any chance of the code regressing (because you had the wrong version of a C++ header file or the wrong version of a class file or other build dependency).

IT Governance

Whether your company has to comply with Sarbances-Oxley, SAS-70 or almost any other compliance framework - the best practices that we discuss at CM Crossroads will help you get across the finish line while still maintaining your sanity. The CEO of one company once mused that in my work we actually try to change the behavior of the developers so that they really do comply with the processes that we claim that we are following for compliance purposes. This is true because good process just makes sense and helps everyone do their job a little better. Sharing our lessons learned is also just good corporate citizenship and at CM Crossroads that is a multinational global daily experience!

Choosing your process

Some process improvement experts would start by discussing the required KPAs of the CMMi (I will explain these in future posts) or the practices of a real Agile developer. These are all effective frameworks that may or may not work effectively in your organization. Coming up with a process that will work for you requires that you ascertain exactly what needs to change in order to get the job done in your environment given the corporate culture, technology involved and knowledge, skills and abilities of the members of your team. I call this "just-in-time process improvement." You need to effectively define JUST ENOUGH process to get the job done and help your team accomplish their goals without making mistakes.

In my writing (and soon in CM Today podcasts), I will explain exactly how you can do this. I hope that you will also share your experiences and best practices (via the letters to the editor forum) as well. In my next post, I will describe a "FastTrack" process that I have used to implement SCM solutions in large financial services firms.

Set as favorite

Bookmark

Email this