The organisation will actively prevent you from trying to improve deployments though, they will say things like “Jenkins shouldn’t be near production” or “we can’t possibly put things live without QA being involved” or “we need this time to make sure the quality of the software is high enough”. All with a straight face while having millions of production bugs and a product that barely meets any user requirements (if there are any).
In the end fighting the bureaucracy is actually impossible in most organisations, especially if you’re not part of the 200 layers of management that create these meetings. I would sack everyone but programmers and maybe two designers and let everyone fight it out without any agile coaches and product owners and scrum master and product experts.
Slow deployment is a problem but it’s not the problem.
You sound very defeatist about fighting bureaucracy. If you work at an org with too much management, you can slowly push to move it in the direction you hope for or leave. If you keep ending up at places that seem impossible to change, perhaps you should ask more questions about this during the interview. I've worked at many small companies where there wasn't crazy bureaucracy because that's definitely what I preferred. I also currently work at a megacorp and yes there is difficulty, but being consistent and persuasive has lead to many things slowly heading in the right direction. Things take time. You have to realize why people have made things some way and then find convincing arguments to make things better. Sometimes places do just suck so don't stick around. But being hopeless doesn't seem helpful.
This is more or less Musk’s approach at Twitter - and ignoring the enormous baggage any discussion with Musk brings (if possible) - I would love to see a real academic case study on the effects of that to Twitter - there will be a lot to unpick but my bias is on your side here.
All of which sounds completely reasonable to me, in many situations.
Jenkins is the Wordpress of software development. It's gigantic state loop that runs plugins with no privilege separation. Giving your jenkins instance administrative credentials in production might very well be equivalent to giving root keys to that lone guy in Romania who authored that plugin you never audited. I can understand perfectly why that might not be desirable to everyone.
.. which neatly leads on to
> we can’t possibly put things live without QA being involved
If you deploy stuff in production that never passes QA, why do you even have QA? To fix stuff later?
If they are not empowered they will never have the chance to do a good job or have any pride in their work.
> 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.
In the end fighting the bureaucracy is actually impossible in most organisations, especially if you’re not part of the 200 layers of management that create these meetings. I would sack everyone but programmers and maybe two designers and let everyone fight it out without any agile coaches and product owners and scrum master and product experts.
Slow deployment is a problem but it’s not the problem.