Development Processes

A recent employer has problems with the quality of software they are producing. They also have issues with cost and time to market. So, they're interested in changing their development procedures. A couple of years worth of losses is a really good incentive to improve performance.

As with many groups, there are problems with their approach. The individuals steering the development of the methodology don't actually have development experience. Even if they have been developers in the past, it was with unrelated technologies. This leads to difficulties during methodology development. Since they don't really understand the work that their engineers are performing, it is more difficult to determine what are the real problems.

This lack of local knowledge leads to the search for the quick fix. They look at the books and say "We need to be CMM level 3!", or, "We need ISO 9000 certification!" - neither of which say much about the actual goal - quality.

I believe that methodologies need to be tailored for each organisation. While it is possible to take a methodology off of the shelf (for example RUP), such a big bang approach is highly risky. The team not only needs to learn the new process, they need to keep on producing software! In such a situation, it will be very difficult to identify the causes of a project failure. Is it because of the new process, poor engineering, or poor requirements? It isn't possible to tell.

Additionally, there may be problems with the methodology chosen. Some practices may not be appropriate for the field. For example, waterfall isn't appropriate for skunkworks teams. Skunkworks projects work in a prototype, iterative approach, while waterfall is all about up front design. While waterfall may result in more determinism, it dramatically hinders the goal of a skunkworks project - exploration.

If a methodology is grown, each new process can be implemented independently. That way, it is possible to reduce the risk to the team while still moving forward. It also allows the team to select only those practices which make sense for their team. Configuration management, nightly builds, automated regression testing, code inspections, design reviews, joint application development - all good practices - often considered "Best Practices". They may not, however, suit your organisation.

Before moving forward with practice changes, the drivers of the change need to communicate and get buy in from the engineers. The set of "Best Practices" is context driven, and changes from team to team. The engineers will more than likely have ideas on what needs changing, or what doesn't make sense".