> we can’t possibly put things live without QA being involved
> we need this time to make sure the quality of the software is high enough
I've only developed software professionally since 2012, but in that time not only have I never encountered such sentiments, but (and, perhaps, because) it has always been a top priority of leadership to emphatically insist on the very opposite: day one of any initiative is Jenkins to production—often directly via trunk-based development—and quality is every developer's responsibility.
At the IC level, there was no "fighting bureaucracy," although I don't doubt leadership debated these things vigorously, from time to time, especially as external partners and stakeholders were often intimately involved.
> I would sack everyone but programmers and maybe two designers and let everyone fight it out
That works for me! But it doesn't scale. We definitely have to keep at least one product "owner" or "expert" or "manager" to enqueue stakeholder priorities and, while this can be a "hat" that devs and designers trade off, it's also a skill at which some individuals uniquely excel.
All that being said, I don't want to come across as pearl-clutching, shocked Pikachu face about this. I understand that many organizations don't operate this way. The way I've helped firms make this change is via the introduction of a single, experimental team of volunteers dedicated to these practices—one protected (but not dictated to) by a mandate from on high.
> we can’t possibly put things live without QA being involved
> we need this time to make sure the quality of the software is high enough
I've only developed software professionally since 2012, but in that time not only have I never encountered such sentiments, but (and, perhaps, because) it has always been a top priority of leadership to emphatically insist on the very opposite: day one of any initiative is Jenkins to production—often directly via trunk-based development—and quality is every developer's responsibility.
At the IC level, there was no "fighting bureaucracy," although I don't doubt leadership debated these things vigorously, from time to time, especially as external partners and stakeholders were often intimately involved.
> I would sack everyone but programmers and maybe two designers and let everyone fight it out
That works for me! But it doesn't scale. We definitely have to keep at least one product "owner" or "expert" or "manager" to enqueue stakeholder priorities and, while this can be a "hat" that devs and designers trade off, it's also a skill at which some individuals uniquely excel.
All that being said, I don't want to come across as pearl-clutching, shocked Pikachu face about this. I understand that many organizations don't operate this way. The way I've helped firms make this change is via the introduction of a single, experimental team of volunteers dedicated to these practices—one protected (but not dictated to) by a mandate from on high.
But, then again, this is California.