I'm experiencing a similar sort of situation, developers are in this case all savvy and the code quality is good.
I judge our issues stem from uncertainty in three elements:
- we're a new team and our functional experience is very different (or call it diverse)
- we lack some knowledge that is pretty core to the intended application design (the ecosystem is huge and discovery is a slow process)
- we don't have an actually project manager and the actual PO is almost completely hands off (scope is a blur)

I think identifying and acknowledging unknowns and uncertainties are a good start, and as it happens, it's nothing unheard of.
Teams can take time gaining efficiency, but if they are serious about improving, then they will. Immensely.
I've gone through situations like this one many times, and despite all the uncertainty, I'm confident in the outcome of our product and of our team, so long as we stay confident and methodical about improving ourselves, our team, our processes and yes, our company. Improvements have already been massive.

Agility ohh _
The only really important aspect of agility is introspection and the spaces created to objectively and respectfully be critical of most everything. At all levels. (personal, team, project, and team or project context).
It doesn't necessarily mean specific meetings, but it does mean being critical of the current me/us on regular basis ~ possibly just keep an ongoing checklist).
That's the linchpin.

Communication is likely where you'll ultimately get the biggest win (knowledge transfer means level up in all sorts of dimensions)
Communication is also where you potentially stand to lose most longterm...
It's a long ongoing process that is pan-project.
Efficient communications are on point. That's:
- concise,
- on topic,
- structured
PRs, docs, slacklike code blocks, tight dailies, (and tight deadlines :-P) are all good training grounds for efficiency.
Note that those skills will help anyone facing a task needing some break down.
Trust and respect mean clearer thoughts and more direct communications.
Work on teambuilding. There's lots of ways to do it. Sharing a screen a and keyboard once in a while is a great way to get to know how other developers think and work.
Going out for drinks and knowing a little about each other is a good way to learn how to respect each other beyond the simple coding.

Uninterrupted flow is key to good code production right?
- Working on communication can bring synergy within the team, each just knows when's a good time or not a good time for the others.
- Practiced com channels are also generally less disruptive.
- Set aside chunks of coding time for the team?

Tests: In my experience, bad tests/testing is most caused by not enough time to write good tests. Getting better at that might be a case of devoting a sprint priority on the test process, frameworks, ease of use, and task definition. Everyone should be comfortable writing the required tests.
Having an already started codebase and test backlog actually helps because you'll more easily uncover patterns that you may have missed in the stress of running late. Testing becomes a lot easier if you've actually given it enough effort to mark a significant improvement.

The project itself:
Most aspects of a project are tied to the delivery itself.
Hazy goals and a hazy roadmap to delivery (the deep level roadmap, tech bit by tech bit) are very disruptive to one's focus.
Thankfully as you avance in the fog you will acquire visibility.
Some will gain visibility faster than others (like the PM and any dev tied to the app plumbing), but on a technical standpoint you need a team that is confident in the roadmap; not in a sense of time, but in the sense of all the necessary steps that need to be taken in order to achieve the goals. Confidence in someone with that confidence can also be enough to go on.

With a bit of confidence in your pocket, each step of the way can be a lot more focused. Developers don't need to constantly be looking in the distance and face the looming deadlines, but can instead focus on the present problem, knowing (or working on accepting), that it's a necessary step, and that there will simply be another after that. Better focus.
Productivity-wise, the mindset is simple: "Oh my next goal is that, and I need to take those smaller steps to reach it, well the path is clear, let's do it and simply get it done."

A simple metaphor would be the climbing of a nice big mountain. There's a point at which the effort is such that it's easier to just stare at one's feet, and just take a step at a time (ah and there's less tripping over roots).
As you go up, you gain strength and stability, and you can start keeping your eyes ahead more. Remember to look at the view: wow what a beautiful sight this and that is! Look at how high we are, look at that beautifully challenging clifface we're going to be tackling :p
It's the journey right? Savor it or make it so.

As a developer, we have to be able to focus enough, but there is a lot of shakeout that needs doing while we gain visibility and efficiency.
At first, the confidence may need to come from the outside (from you): trust in the team's individual qualities, trust in the introspective process.
As time goes, the confidence comes from the increased visibility, achievements, the increasing smoothness of communications, the increasing trust, awareness and confidence and respect of each developer for they own selves and their teammate's strengths and weaknesses (face them and improve on them eh?)

Risk.
Figuring out your unknowns early is critical to correctly evaluating your deadline.
Unfortunately it's also not very good for confidence building as tackling risky aspects of the projects is generally hard and not very rewarding productivity wise, though it has huge longterm benefits.
During those times, acknowledge the current situation, and focus on the positive aspects of the project: typically at that stage, visibility is increasing, some team processes may be falling into place, we've identified all these pain points, etc.
There's discovery going on in all sorts of directions and though it's daunting it's a good thing.
Also, once those risks are better known, and perhaps dealt with, your output speed is going to increase rapidly hurray. (Note: change in velocity also might mean need for readjusting things eh?)

The deadline?
You'll note that I haven't really worried about any actual deadlines.
Here's the thing: knowing your team is actively working on improving itself, you should have confidence that they are working at best capacity at any one point in time.
If the deadline is too short, what can you actually do? Make your team magically better? No, of course not. You can only give them your confidence in that they are doing their best. Yourself, focus on realigning goals, load, priorities, timelines and resources. Give them the time and tools they need for self-improvement and be a driver for that improvement.

Rituals and all are pretty good, but do allow flexibility and allow everyone to be critical of them. Standards can be a good skeleton, but the principle is that you need to continuously fit things to your needs.
Meetings should be adding clarity, but they do take some focus away as well don't they?

My 2 cents, I hope it helps, though I realize it's all somewhat intangible and way too verbose.