What you measure is what you get

"...In fact; probably, what you measure is the only thing that you will ever get" said one of my colleagues over a lunch meeting, many years ago. I kept pondering over it for long after the lunch was over and decided to put it in action.

 One of my teams, those days, was struggling with bad customer reviews and a high number of incoming and outstanding post-production issues. The team seemed to have gotten into the loop of quickly completing modules, move to the next module and then fix bugs in previous modules as they arrive. This, everyone agreed, created quite a bit of a headache, both in terms of negative customer feedback and mounting bugs count.

We decided to measure starting with a number of incoming bugs for each piece of code that made to pre-production and set realistic targets to bring that number down release by release. Team also decided to treat QA team as their first customers and realised that we didn't want to "throw trash" on our first customers, therefore unit testing and code reviews automatically strengthened to ensure a favourable feedback from our first customers. Definition of Done was enhanced too.

 To measure the feedback from our first customers (the QA team), after every release we solicited feedback; asking them to rate the quality of goods received on the scale of 1 - 5. Every feedback was respectfully received and a thank you note was sent by the module owner, followed by a detailed feedback meeting if needed. First few instances taught us a lot about how QA team found bugs on the surface and didn't find enough time and motivation to dig deeply buried issues that often manifested in customers' use. 

This newfound  wisdom also resulted in quite a bit of self-discipline  in the team, in terms of creating a robust Definition of Done, proper documentation and review of unit test cases and a good architecture diagram to go with the code.

We created a "Wall of Fame" where print-outs of feedback were posted, this became a fun way of measuring the success and opportunities to further improve.

Within a few months, customer issues were much more manageable. More than that Dev and QA teams had developed an excellent camaraderie and mutual respect. The team came up with a few other metrics to measure the ongoing quality.

I have personally put this theory to test several times and it has never disappointed me. if you want results, find the effective metrics and start measuring.