A frequent concern for adopting agile practices is when to do it. Most would prefer to do a major transition of practices and roles at the start of developing a new game. There are definitely benefits in timing training and a shifting of roles and responsibilities then, but it's not the only option.
Often teams will start getting into trouble with quality issues and looming ship dates as they close in on that ship date. They'll want to make changes but assume it's too late. It's not.
Recently I visited a team that was a few months away from their first release on Steam. They were confronted with a ton of debt and there wasn't much direct cross-discipline communication going on. After some training, which included deep conversations about the short and long term vision of where to go, they decided to focus on prioritizing the debt and improving the definition of done. This slowed down the introduction of new features they wanted, but it allowed them to better triage the quality of the game. They agreed that the quality of the existing game was more valuable than the number of features.
What they didn't do was radically reform the teams to make them perfectly cross-discipline. A few key changes were made and some over-multitasked people were helped out, but we agreed that overhauling the entire organization at that point was too risky.
This training and discussion took several precious days away from people focused on delivery, but we felt it was worth it. Sometimes we get so focused on what we're trying to do that we forget how we're doing it and how we can improve that.