How Much Process is Enough? Just Enough

by Brad Hart

Hi, my name is Brad Hart and I am the Director of Technology at AccuRev, Inc. I’ve been working in the software delevelopment / process space for 10+ years. I’ve designed and supported numerous ClearCase / ClearQuest implementations both while working at IBM/Rational and as a customer at various companies. At AccuRev, I’ve been involved with countless implementations of AccuRev with our customers, everything from small to large, ISVs, Internal IT, and Embedded systems companies.

Over the years, I have seen so many different approaches for software development in all kinds of companies. One area that every company seems to struggle with is defining their process. There are many stakeholders in the development process (Developers, QA, Release Engineers, Admins, Management, etc…), and it is a difficult task to get everyone on the same page to ensure that the defined process meets the needs of everyone. One area of particular contention is the amount of process to use. I’ve worked with small companies with a handful of “cowboy” developers which had absolutely no process, and I’ve also seen the opposite end of the spectrum with so much process at large companies that it gets the nickname “pebble moving.” Neither approach works.

In the no/little process environment, developers just do what they want, where they want, and how they want. This freedom certainly seems nice for the developers. I’ve never met one yet who was yearning for more process… However, this hurts the company (including the developers) in the long run. Release Engineers have a difficult time reliably building and reproducing software, parallel development is held to a minimum, Admins lose control of the assets, Managers cannot track progress and at the end, less software is produced and what is produced is lower quality. The positive side is developers spend 100% of the time coding and 0% on process overhead. The negatives are poor software, slow delivery and regressions.

The opposite end of the spectrum is equally inefficient. Have you ever seen an issue tracking schema with 10+ tabs, 100+ fields, and a state transition workflow that can only be described using 5+ visio diagrams? I have…many times. In an effort to control each step that everyone takes, these companies suffocate their developers with way too much process. So much so that they cannot work at even close to their full efficiency. They may spend as much as 30% – 40 % of their time working within the many steps of the process and not enough time coding. From my experience, developers react to this in 2 ways. (1) They just succumb to it. They simply accept the are not working at full capacity and move on. This of course means the organization is only 60% effective and can only produce 60% as much software as the next company… (2) They rebel. A motivated developer will find a way around the process so they can be more “efficient” and get more code written. Their intentions are good, but the results are bad. This approach almost always results in disaster: broken builds, regressions, lost work, etc…

So what is the answer? Just enough process. Just enough is going to be different for each company and even each group within a company. It also is a moving target based on changes in business requirements, company growth, etc… The right thing to do is to get representatives from each stakeholder group and work together to define what all the end goals and requirements are:

• How many releases do we need to ship per year?
• How many releases at a time will we support?
• What is our patching strategy?
• Do we need to support distributed development?
• Are we working with partners or 3rd party vendors?
• Will we support customer one-offs?
• What are our testing requirements and ship criteria?

Once you have the answers to these questions, you can start working on the process. The goal behind any process design is not to have a beautiful and elegant process. The goal for the process is to facilitate all actors in the process in doing the right thing and putting up just enough guardrails to keep from accidentally doing the wrong thing. Keep each business goal in mind and think about what it will take to make sure every actor has just enough information to accurately complete their task and just enough protection in place to handle common mistakes. That’s it. Don’t go overboard. That is just as bad as not having enough process. Don’t overwhelm people with information or steps to complete a simple goal. Should someone really have to fill in 40 fields to submit a defect? I don’t think so, but I’ve seen it. Keep it simple and straightforward. Just enough process is the key.

Also, make sure the tools you are using support the processes you’ve outlined. They should be able to implement your desired process and be able to adapt to changes in your process requirements.