How can you optimize productivity and efficiency for an application development team?

According to both my experience and a wide body of research, the most significant element, besides technical competence, is psychological safety. Everyone needs to have a voice, and there should not be just some few, identified by their badge, allowed to contribute creatively. Conflict has to be expected and is a natural phenomenon that normally occurs, e.g. whenever there is a change to team composition. Team leadership must be mature enough to allow conflict to occur in a mature way, as trying to suppress it would just make it more covert, dangerous and ultimately destructive. Transparence and open communication are key: if a problem is not reported, for fear of being "wrong", "losing face" or similar, it cannot be addressed.

The methodology itself is vastly overrated. A competent team can adapt to whatever methodology and still deliver a working product, in time. Problems with methodologies generally arise when incapable technical and managerial leadership espouse a methodology expecting it to be a silver bullet, and follow all the prescribed steps, ticking all the boxes, but without a project vision, and failing to see the complete business and technical picture. Also, if there is not a domain expert in the loop, aiding development, you can claim being agile as much as you want, but you are not. And it is absolutely useless practicing mobbing, or XP if there is no shared trust. Without trust you don't even have teams, call them workgroups instead.

Code standards should be based on what count most, the quality of the code, and not focused on code aesthetics. Use a linter and enforce its use, rathe, but do not allow discussions on code formatting to become more important than actual code quality. The purpose of code reviews is not enforcing a common style, or perfect uniformity, it is above all catching bugs. Pairing can potentially substitute code reviews, but please avoid at all costs mobbing sessions with three or more developers: one developer will typically ally with another; the dysfunctions of small social groups of three people, with unsteady and continually shifting power struggles are amplified. Never use "time under review" as a metric affecting dev performance reviews.

Keep an eye on accumulating technical debt and allocate time to address it. Neglecting technical debt can slow down the development process over time

Having someone who is the line manager of the rest of the team contributing to the code-base is a e massively bad idea. It leads to huge conflict of interest, with the developers not willing to criticise the code of their boss, or fearing to be considered not intelligent enough, if they find it too complex. This kind of conflict of interest leads to inefficiencies, higher risks and technical debt.