Often companies ask me:

 “How do we know if this process is successful? How do we measure if this process is working for us?”

I don’t think any process by itself can make someone successful. A lot depends on the company, its values, principles, nature of business, its people and so on.

If I wanted to introduce a new process into my company, this is what I would measure or look for:

• Is it helping my product/organization? Things like
• time to market,
• frequency of releases,
• perceived quality/stability of the product and so on.
• Basically aspects about my product delivery which were good (want to continue doing them) and aspects which needs improvement.
• Is the team evolving the process? Are they internalizing the process and reducing the amount of ceremony?
• While the process should encourage people to do reflective improvement, it should also encourage some amount of disruptive changes thinking into the teams/company.
• Is the process creating growth opportunities for my people?
• I would like the process to encourage growth in terms of them becoming Generalizing specialists and not being corned into silos.
• I want my people to improve their overall understanding and involvement in the overall product development process rather than just knowing or caring about their little piece.

Also Jeff Patton has a wonderful article on Performing a simple process health checkup:

He suggests we look for the following “properties” to assess the process’ health:

1. Frequent delivery
2. Reflective improvement
3. Close communication
4. Focus
5. Personal safety
6. Easy access to experts
7. Strong technical environment
8. Sunny day visibility
9. Regular cadence

I would like to add 3 more properties to this list:

1. High energy
2. Empowered teams
3. Disruptive change or Safe-Fail Experimenting

In Software, Quality is one of those badly abused term, which is getting harder and harder to define what it really means. I think we have a sense of quality. When we see something in a specific context, we can say its high quality or low quality, but its hard to define (and hence measure) what absolute quality really is.

You can measure somethings about quality, but don’t fool yourself to believe that IS quality.

Quality is subjective, relative and contextual.

Some might say things like code coverage, cyclomatic complexity and defect density is a good measure of quality. I would argue that those are attributes/aspects of quality, but not quality itself (symptoms not the disease itself.) Its a classic case of Fundamental Attribution Error. (If you go to France and see the first 50 Frenchmen wear glasses, you cannot conclude all Frenchmen wear glasses. Nor can you conclude that, if I wear glasses I’ll also be French.)

BTW people already differentiate between Internal/Intrinsic Quality and External/Extrinsic Quality. This is not enough to complicate things, evangelists would like to further slice and dice quality along different parameters (structural, functional, UX, etc.)

Some anecdotes:

• What is Quality
• Don’t be Seduced by Code Coverage Numbers