Overdefining the process

My personal dilemma has always been that I find that many of my colleagues, who promote use of the SEI's Capability Maturity Model, ISO 9000-3 and even so called lighter methodologies (e.g. Agile methods), are often more interested in "defining the process" and less interested in getting the work done. Vendors who promote methodologies are usually more interested in justifying their suite of products than really looking at the most expedient way to get the project done. Many of these nice people have never been in the trenches a day of their life. One gentleman once explained this position to me, "I have never laid an egg, but I am a better judge of an Omelet than any chicken!".

I often joke that Software Process Improvement experts often sound like an IRS auditor, "Hi! I am with the IRS and I am here to help you."  Actually, defining a process usually feels like it is creating more work for everyone with little added value. There is a way to make Process Improvement work effectively without the team feeling like it is all a waste of time. Let's take a brief look at the CMM and then how we should really go about considering the most effective way to define a process and the behaviors of the people who will have to follow it.

It is not easy to read through the CMM and actually understand what you need to do. Level 2 Key Practices (KPAs) of the CMM discuss Requirements Management, Project Planning, Project Tracking and Oversight, Subcontract Management, Software Quality Assurance and, of course, Configuration Management. I have always been mystified as to why Peer Reviews and Training come up in Level 3, instead of Level 2. It gets even worse when we start coming up with a long list of things that I need to do in order to say that we are at Level 2. Many practitioners warn sternly that you must not skip levels, but I have to search even further to find out when I should focus on software design, coding, testing (SQA is more of an audit function than software testing) and software maintenance. 

Why do we need to do all this? Usually, a very effective software development team grows just big enough that they suddenly need to start having more formal processes. This is usually apparent when there are a couple of serious problems. For example, there is a problem in production and it takes half a day to fix a simple issue because no one is certain as to which version of the source was used to create a particular release. My favorite is when a problem happens in Production and no one realizes that we should have updated our test suites to check for this issue during the integration testing and User Acceptance testing. Defect Reports should always generate a new test case!

The Software Process Improvement expert needs to show a little respect for the other developers on the team. We need to start by assuming that everyone is doing the right thing at the right time. Often SPI experts come in making changes to the way people work and force new ways of doing things when nothing is broken. This is a waste of time and also causes us to loose credibility with our peers (and rightfully so!). The goals of the process improvement effort must be defined up front.

Some examples:

Any successful project must be planned out and controlled with an effective Project Management approach so that Senior Management has visibility into the project and more importantly so that the rest of know what has to be done and by when. Decisions can be made up front in terms of staffing, training and technology selection when the project has effective Project Planning and Controls.

Requirements specification is very hard to do well and the lack thereof just results in failing to meet the customer's needs, cost overruns and bad code.  Methodologies such as RUP, Agile and Iterative Development are making huge improvements in helping us see the most effective way to communicate what code needs to be written and how the system should work. UML diagrams, use cases and, my favorite, writing brief test cases before the code is written can save a lot of time and effort.

I usually start by asking the team what they are doing right and what practices they could share with others. I start by assuming that my colleagues are professional and that they know exactly what they are doing. I respect them and will bend the process model if they have another way to meet our goals already. But if the goals to manage the project are not being met or there are significant testing, release management and deployment issues then we need to take a look at what has to change in the process to meet our goal. There are definitely times when we must insist on changes or we just won't succeed. I have often found that training is the "hill to die on". For example, trying to use a robust version control tool without training is just a waste of effort - and often results in lost code. Similarly, overly complex branching does not work either.

Back at the Police Academy

Many of my readers know that I love to be involved with community service.  Flying around in an ambulance or police car is strangely relaxing - especially when you get to help someone. To qualify to patrol on a bike we have to attend training which includes an endurance run (I had to do mine in the middle of the winter!). There are a lot of drills that must be passed (e.g. picking a gun off the ground while you are riding). Some of these tests are pretty hard, but they all seem fair and reasonable given the job of the Police. We can learn a lot from this approach. Our process improvement initiatives will also be challenging but they must be fair and reasonable and then our colleagues will often rise to occasion and exceed our expectations.

The CMM and ISO 9000-3 have often been criticized as methodologies that tell you "what" needs to be done, but they fail to tell you to "how" to do it. It turns out that is exactly how Software Process Improvement professionals should be working. We should get into the trenches and understand how the job is getting done now. We need to be leaders in that we explain and promote the vision of where we need to be. Then we can make effective use of best practices and help the team improve their development practices in an effective and successful way. There are times when we must insist on following process improvement models more literally - especially when the home grown approach is just not working. Our job is to add value by being knowledgeable about the Process Improvement Models and methodologies, best practices and most of all remembering that we are in business to be successful. As an SPI professional we must always, define the goals up front and provide effective leadership for success!

 TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed