The Agile Manifesto says "Deliver working software frequently". Learn to do that. The rest will follow.

Lately I've been inundated by people talking about how you need "Lean Principles" in addition to "Agile" in order to be successful. I've been swamped by people asserting that teams need to have hooks and ways to decide which "Agile" meetings or rituals to add or remove from their work.

No. Just no. Not until you can deliver working software frequently.

Can you deliver?

If your team can deliver working, well-structured software, every couple of weeks, about as much as you predicted, software that your customers and stakeholders like, then you might benefit from looking into the nuances.

If you can't deliver what you said you could;
if it doesn't work;
if it isn't well structured;
if your customers and stakeholders don't like it,
then your problems and their solutions are not subtle.

Here's all you need to know between now and when you can reliably deliver what you set out to deliver, in good working order and well crafted, resulting in what your stakeholder likes:

How to deliver:

Are you not getting everything you take on finished? Then take on less.

Are there defects in your code? Then test it sooner and better. Try pair programming.

Is your code hard to work with? Then refactor it as you go.

Is it hard to integrate? Then integrate smaller pieces more frequently.

After you give it to them, do the customers dislike it? Then talk with them more before you start.

Are you still not delivering solidly? Then think about how to improve every week or two.

Think in terms like those above. Those are where your problems are. Do less, do it better, do it more frequently. Work with the customer.

Isn't there more to it?

Until you can reliably deliver what you thought you could deliver, focus on how you define and build software. You don't need Lean or Kanban or to improve your stand-up meeting. You need to learn how to define, build, and deliver software.

You'll need to take on fewer features, and you'll need to make each feature smaller.

You'll need to learn testing in advance, like ATDD and TDD, and you'll need to learn a bit more about testing after implementation as well. You'll benefit from pair programming.

You'll need to learn how to refactor and how to use your refactoring tools.

You'll need to learn how to use a code manager and build system.

All that information is out there. Most of it is probably in your team's heads, at least as ideas. You need to learn how to do those things, and then you need to learn how to do them well. In essence, learn how to deliver.

Repeat the above until you can deliver.

By the time you're good enough to build what you anticipated, working, clean, making people happy, you'll be good enough to decide about more subtle matters.

Just keep on doing what you're doing and continue to think about it. Now -- and very likely only now -- you'll need to consider deep principles, the forces and reactions, or the subtle actions of hyper-dimensional beings on your team.

Until you can deliver, work on delivery. Work on nothing else until then. The rest will come in due time.