As a consultant in Quality Assurance, when I arrive at a new client or start a new project at an existing client; one of the conditions of satisfaction expressed by my stakeholders is that they want a high-quality result delivered at the end of the project. That’s not an unreasonable ask if a company is intent on spending money to better their products and services. Where the hurdles come in are the mixed messages on what ‘Good Quality Work’ is. Having started my career in the position of doing on manual testing and then moving up the chain into managing Test Services teams, I’ve come to the realization that customers tend to muddle ‘Actual Quality’ vs ‘Perceived Quality’. Whats the difference you ask? People have been programmed to perceive that their projects must go live with zero defects. Some companies will work tirelessly to achieve the concept of zero defects. What’s not being asked is if this approach hurtful in the long run?
Teams can get burned out when they are met with a goal line that constantly moves because of today’s software development speeds. So what are some key things to do when asked to deliver a project with near Flawless Quality?
1) Velocity, not Throughput
When focusing on velocity, it behooves your situation to step back and help establish a baseline with historical data. If you don’t have history, then it’s recommended to help establish a velocity marker as soon as possible. Being asked for a projection of where you will be is not possible without an establishment of where you are and where you have been. Throughput is a very arbitrary measurement that most teams fall victim to. If X does N amount of work in Y amount of time, then we should be able to achieve Z. Luckily, that challenge can be circumvented with an open assessment of what a team’s workload is. Not everyone will be tasked with the same amount of work. Help your clients create this set of measurements project quality assessment.
2) Prevention, not Remediation
“How do we fix this?” This is a question I’ve heard too often from clients who are perplexed at the fires raging when their projects are getting close to done or already live. I recommend broaching the conversation of how Quality is created upstream at the requirements stage of the project. A team simply cannot test quality into a project. Good requirements, clear expectations of results and expressed conditions of satisfaction are the best way to nip issues in the bud when it comes to murky requirements or the inevitable ‘this isn’t built as designed.’ This is the hardest culture shift to enact on a client site; especially if you have teams that are not communicating because of the fear of being the bearer of bad news.
3) Fuel, not Fires
It’s important to help teams rise above the noise of firefighting when it comes to issue management. Quality is not about what the end product looks like after months of firefighting; it’s about building a consistent, repeatable and process-oriented practice that provides a level of predictability. Project delivery is dependent on the ability to shift and move as the unforeseen occurs. Building a set of metrics, consistent but flexible toll gates and transparent communication is key to delivering on-time and with higher than anticipated quality.
For more information or to discuss further, please feel free to reach out to me at firstname.lastname@example.org