An Agile Leap of Faith

For me the hardest part of moving from a waterfall to an Agile environment has been the "What are they doing in there, anyway?" factor.

In a waterfall environment I received requirements documents that I translated into technical documentation that were in turn translated into time estimates.
There were meetings.
Lots of meetings.

Everyone signed off on everything after reviewing the documentation. Only after that process, which sometimes spanned months, did we start coding anything. After the code was written, it was reviewed and then shipped off to a QA division for testing. I recall this process taking well over 6 months on more than one occasion before a single line of code was written.

In Agile, most of that takes place in a span of about ten working days.

That span is called a Sprint. The design work is largely done during an all-day Sprint Planning session on the first day of the Sprint.
The customer drives the product through Sprint Reviews ten days later where they have the opportunity to actually use working software and tell you if you got it right. Nothing is presented to the customer until it meets the teams Sprint Definition of Done; no smoke and mirrors allowed. Documentation is still important but the emphasis is very much on working software.

All of the requirements documentation, technical specifications, code reviews, testing and high performance means absolutely nothing if your code isn't what the customer wants.
Consequently the Agile team works directly with the customer in two week increments to help ensure they're programming something with a high ROI. So. I said all of that to write about the "leap of faith" in the title post.
There's pride-of-ownership that develops on an Agile team that I've never seen form between people in a waterfall environment. I've worked with many, many talented developers who very much take pride in what they're working on (and come up with some of the greatest ideas I've seen) but they might be working next to someone who doesn't care-and in the end they both suffer the consequences vis-a-vis the product performance in the market place.
In Agile, everyone on a team is responsible for the code the team produces and it shows.

The trick is taking that leap of faith and letting the team work through issues themselves and help foster pride-of-ownership.

How? Don't direct the team to solve an issue a particular way because you become the person who's blamed when your way causes the project to fail.

Conversely, if the project succeeds the team can't take credit for actually solving a problem because you told them how to do it.
You lose either way.

You have to learn not to care so much about how they're doing something, only that the team is producing working software in a volume you, and more importantly the customer, is happy with. All Agile teams will get to things done a different way.

Sure, they're all going to be following the basic rules-standups, storyboards, sprint reviews, etc.

but each team will develop it's own culture; what works for one team won't work for all of them.
Give the team the tools they need to get the job done and get out of the way.