I've been asked this question a bunch; I think it's typically to see if I'm a good fit for early stage companies. Early on teams are a lot more chaotic and informal, but eventually process and formality are added in. I think it's ideal that when transitioning you take a more as needed approach. By that I mean as problems arise that you are willing to invest time into fixing then add in whatever rules, processes, rituals, etc that solve the problem. This is opposed to saying okay, it's time to go full agile and changing everything.
I do think it's also work thinking about whether or not it is worth solving. Some things that I consider: Did someone accidentally poison a cache and it took hours to track down the root cause? It has a high severity, so I'd go ahead and make that cache immutable. Is it something that comes up often, green light a well. Is it something that's only come up once and wasn't a big deal? Then try to wait and gather more examples so you can better come up with a solution. Bad abstractions a source of pain and this is pretty similar, the less disruptive we are the better.
So there's no simple answer. It depends on the the stage of the company.
Ultimately I like to follow dual track development. That is to say there's 2 teams within a pod: A discovery team that is made up of the product owner, designer, and lead engineer. They are responsible for looking into designing solutions for upcoming projects. The product owner and designer are more involved in this stage, they are the experts on the product, customers, and established design patterns. Where the engineer is there represent the well... engineering side of things by being an expert in what's possible within the current system and how much effort it will take to build this new thing. They often can help come up with alternatives that might get you there twice as fast, but 80% of the way -- something that the product owner can use to decide what level of investment the company wants to forego. The delivery phase is basically the opposite when it comes to who is most involved. It's time for the traditional agile practices and for the engineers to get to building. Product and design are involved to answer questions, groom, and help solve some unthought-of problems as they arise in the middle of working through the project. That's about it. What works best will depend on the team and stage of the company and later on I prefer traditional scrum with dual track development.