Build a deployment server and a dev server. You can do this without the team knowing. Do a swot analysis with the team. Make them answer why it takes days to d

Build a deployment server and a dev server. You can do this without the team knowing. Do a swot analysis with the team. Make them answer why it takes days to do simple changes. Make them answer how they'd recover prod if the disks died. Block access to prod. The team has to code on Dev and upload their artifact to cicd. They'll hate the change but it's policy and it's enforced. What are they going to do? Block artifact upload to deployment. They have to merge a branch instead. Be extremely available to help them learn the SCM tool. They'll hate the change but policy, etc. Set up a work tracker that lets you link bugs to features. Populate it with historic data. Triage it extensively. Show the team how each bug comes from an earlier change. Show the team git bisect. (You'll need a test server at this point.) Set them a target: average time per feature or issue. You'll abolish this metric once it's attained for the first time. In the meantime, it's hard to game the metric, because the codebase is fucked. Wait, and see if they come up with anything on their own - dinner is cooked when it starts making interesting thoughts. If they fail to work it out, you'll need to coach them. Give them little breadcrumbs. You want them to understand: - slow delivery == poor business outcomes - bugs == poor business outcomes - git helps with bugs - cicd lets you write code - testing reduces (delivery time + bugfix time) Only when the team understands this can they do the work of fixing the app. (IMO that's a total rewrite, but you're not short of advice ITT.)