It’s MVP Monday, but today we are hearing from 1E’s VP of Engineering, Sean Capes.
Recently at 1E, we’ve undertaken a fairly fundamental change in our development practice: we are getting our software engineers to own quality control. Of course, the mantra of the team owning quality is well known and applied. Scrum teams is an example of the self-contained ownership and empowerment of teams. However, even within self-organized structures such as scrum, I’ve witnessed that most teams still apply the “mini-waterfall”. Software engineers create the software assets and ‘throw’ them over the wall to QA engineers.
“I build it and you test it”.
This can result in a lag between the code being completed and then fully verified; I’m sure you have experienced ‘code complete’ but without the definition of done, and quality control happening in a later iteration. Another sign of this behavior is the regression or integration sprint. This can equate to ‘cleaning up all of the quality issues I failed to complete in a previous iteration’. Effectively, deferring quality assurance, and applying ‘quality on credit’. I use this term because any delay between code complete and feature complete is a cost to our business.
There are obvious perils in allowing software to verify their own work. My experience with TDD has shown that there can be issues where the testing fits the design rather than the problem. And here, the same can apply. Without a quality focus on seeking deviation and problems, a software engineer is often solution focused rather than problem focused. There are exceptions of course, but QA engineers are familiar with this domain. A drive to find failure.
So, at 1E, we still continue to have close collaborations and self-organizing teams. However, we now have QA engineers guiding our software developers on how to test. They jointly co-author test cases and this then frees up QA to focus on the entire quality assurance, both strategy, and quality control. This mirrors some aspects of hardware manufacturing, building in quality control as part of the manufacturing process. Of course, the difference is that the widgets are not all the same but the framework can be consistent. We know that some of this practice has been learned and applied with approaches such as Kanban. But rather than a capacity control framework, the intention is to have a quality control framework: a process that emits quality control metrics as part of normal development practice and enables us to reduce the investment credit.
Some such enterprises as Google and Microsoft have already applied this in some areas with varying success. We don’t have such vast development budgets to afford significant mistakes. However, we do have talented teams, agility, bright people, and an embedded willingness to adapt and improve. It is the start of a new journey for us. I’m confident we can start to reduce our quality credit bill.
