Occupy Quality – Secrets of the ‘Very Satisfied’
Collaborate | Posted April 11, 2013


I was recently in a conversation with a friend of mine about a book on managing your finances. Shaking her head derisively, my friend said something along the lines of, “I thought a lot of it was good, but am I really taking advice from a billionaire on how to manage my money?” Hell, yeah! I replied. Who else would I want to learn from?

My philosophy is this: to be the best, you have to learn from the best.

This is true in software as well, which is why I was so intrigued by some of the findings from a recent survey on code review that SmartBear Software conducted. We reached out to the software development community via several online technical publications and websites, and had more than 600 respondents. We learned a lot of good things in the process (which we’ll share on April 17th in a live webinar event) but one of the things I thought was very interesting was how few people said they were “very satisfied” with their software quality.

overall quality software2

Only 20.6% of software professionals claim to be very satisfied with their product.

So, let’s change that statistic by finding out what they focused on and what practices they adopted to reach this goal. Maybe more of us can learn from them and find ourselves in this category in the future.

Who are they?

Our survey showed that the majority of people who said they were very satisfied with their software products came from regulated industries like medical devices and governments, as well as marketing services where metrics are highly valued. Regulated industries are well-known for their testing and specification standards, driven in large part by the severe consequences of a bug in their products. One could also speculate that having clear quality guidelines and metrics also leads to a greater understanding of your level of quality. Interestingly, the data also shows that large organizations and very small organizations both had a higher degree of satisfaction with their products.

What kind of tools are you building?

How many employees are there at your company?

What do they do?

Considering that we have identified these organizations as being large and mostly regulated, you’re probably expecting large bureaucratic processes for defining their requirements, establishing metrics, and achieving milestones. So, here’s a surprising bit of info: the majority of these respondents are also using Agile development processes. 

The majority of these respondents are also using Agile development processes.

Of course, this study we’re citing is a study about the practice of code review. In our findings, a vast number of Agile teams were also using code review as part of their methodology. The “Very Satisfied” group is no exception – they were twice as likely to be performing code reviews than not. An interesting comparison is with the bottom tier of people who were Not Satisfied with their product quality: those people were twice as likely NOT to be performing code reviews. (In the chart below, Yes means they are using Code Review while No means they are not using Code Review)

very satisfied copy

What do they care about?

Asking someone if they are satisfied with their product quality is a pretty broad question. It really requires some qualification about how that person defines quality. It is very enlightening to see that this group places Customer Satisfaction above all other aspects of quality. This says to me that if you make the customer your priority and you equate Quality with User Experience, you are pointed in the right direction. Considering that “milestones” are the least of their concerns, one has to assume that their daily scrum discussions are focused on the user experience of what they’re building rather than the schedule. Good for them. 

what's most important

Start Your Own Occupy Quality Movement

So what can we do to be part of the top 20% and deliver better software to more people?

  1. Document your guidelines and expectations. Even if you aren’t in a regulated industry, you can create your own regulations to abide by. Make sure everyone knows what your criteria are for good quality.
  2. Don’t give up on discipline. Being Agile doesn’t mean you can’t have disciplined behaviors like code review in your process.
  3. Care about your customers. Put your customers above everything. 

 

See also: 

Close

By submitting this form, you agree to our
Terms of Use and Privacy Policy

Thanks for Subscribing

Keep an eye on your inbox for more great content.

Continue Reading

Add a little SmartBear to your life

Stay on top of your Software game with the latest developer tips, best practices and news, delivered straight to your inbox