“Why is your quality practice so different from the industry standard?”, people often ask me.
Around two years ago I joined OutSystems, as Head of Product Quality and Delivery. I was brought in to ultimately become responsible for improving the quality of the product while continuing to accelerate product delivery. After ten years of working in Quality Engineering and Management positions at Microsoft, I was eager to apply all my learning to the very specific OutSystems context.
OutSystems is a fast-growing and extremely nimble company, with a great product, in the hands of thousands of enterprise clients. Therefore, I knew going in that, whatever we did, we needed to make use of a very particular approach. This has benefited us immensely, so it’s time to spill the beans and start sharing what we have learned along the way.
Tailoring Quality to Fit Our Context
In the Summer of 2016, we reorganized our entire engineering department. This reorganization was meant to address the fact we need to operate at breakneck speed, with several particular requirements and needs.
There are three major forces at play that shape a lot of what we do and determined how we were going to do it:
- Speed is in our DNA. Being market leaders, we need to be constantly setting the pace.
- Fast-growing product and company. We are victims of our success; our company and product keep growing.
- Internal complexity. We manage a lot of complexity so that our customers don’t have to.
We needed to build a distributed model that allowed us to make fast decisions and to continuously deliver our product. Dependency management and problem-solving would be handed over to the people that had the most context and were the best equipped. With this in mind, we split the teams into smaller and nimble cross-functional teams. Each small team had to work as an autonomous cell, skilled and fully capable of making their own decisions.
We knew that this model would only work if the teams also owned the quality of everything they produced. We’d seen in the past that an external team of testers (and test automation) did not work; it also broke the principle of accountability and autonomy that we wanted to foster.
We wanted someone to be responsible for quality as part of the team, to teach their team the skills needed to be autonomous, to own their quality. The teams needed to learn the quality culture, practices, skills, and know-how to successfully deliver high-quality work. At the same time, they would be increasing the pace of delivery and continuing to grow the product and organization. This would be no easy feat!
Five Principles We Build On: The Rise of the Quality Owner
To better understand how to achieve the quality autonomy teams needed, we listed five principles we firmly believe in and that are the foundations of our quality-driven culture:
- Quality is everybody’s responsibility. Not of a single individual or group.
- Development and testing are two sides of the same coin. We can’t have one without the other.
- Customer feedback is king. Delivering fast and frequently is the only way to get it.
- We build quality in. Design for testability and push-left our testing.
- Quality is a lot more than testing. We amplify all feedback loops.
With these five principles, we accurately defined the profile of the people we needed and how they would interact and get integrated into the teams.
And so the Quality Owner role was born!
You might be wondering why we decided to use “Quality Owner” as a title for this role, especially when we strongly believe that quality is everyone’s responsibility. We did it to set the level of influence and impact this role should have on their teams. Like our Product Owners that own product scoping decisions, the Quality Owners own and accelerate quality decisions.
If I had to explain what the role is all about with a single short sentence, I would say that Quality Owners are software architects that choose to specialize in the quality aspects of their teams and product area. Furthermore, they are very technical individuals that can refactor our product to be more testable, solve hard problems, and create test automation frameworks and tools to achieve better results. They typically “belong” to a single team, participating and contributing to sprint goals, taking part in that team’s ceremonies, and events.
For Quality, The Time is Now
The software development industry is changing extremely fast. Decades ago, when I switched from Developer to the role of Test Engineer, “quality assurance” was something you “had to do” at the end of an excruciating long project. Too often I felt like a speed bump in the whole process. I was the guy who was screaming, at the end of a frustrating and already late release, “You shall not pass!”
Very often I was the bearer of bad news… and you know what happens to those guys.
Fast forward to today. The quality practice has been reborn and is a central pillar of the Continuous Delivery and DevOps practices.
“Deliver fast, on time, and with high quality” is the new mantra of the software industry. Companies that don’t invest seriously in quality and in anticipating customer feedback are going out of business or becoming obsolete.
The role of the Quality Owner is now more important, exciting and relevant than ever. Are you curious to learn more? Stay tuned, because I will be sharing further details very soon!