The team sits together, hopefully in a large open space that promotes continuous communication between everyone everyday.  By everyone I mean developers, managers, business people, and even customers. Everyone talks face to face every single day. That is what daily communication means and is essential to team empowerment.
Many Agile processes have a stand up/scrum meeting everyday. One meeting with the entire team can eliminate much miscommunication later. Setting a consistent time and place helps make the meeting happen and adds to the feeling of a project heartbeat. During the daily meeting everyone answers at least three questions; what did you do yesterday, what will you do today, and what blocks your progress. Let this be an honest plan for what you will do today.
When you keep the meeting short you won't have a problem getting people to participate. Scrum has rules about who can speak at this meeting. The customer/product owner, developers/team members, and manager/scrum master talks, everyone else is welcome to listen and take notes. People outside of the team like to show up and drop stressful deadlines in these meetings. You may need Scrum's rule about who can talk if management uses this meeting as a convenient way to lecture to the entire team instead of a give and take communication as intended.

This flow chart shows feedback loops or channels of communication recommended by Extreme Programming (XP) you should have many of them on any Agile project. These communication channels are arranged in a spiral

of granularity and frequency. It is important to communicate within the proper granularity. Don't waste bandwidth by getting too detailed in front of the wrong audience.
If you find yourself explaining details at the higher level ask yourself why? If you feel the need to explain you may be trying to justify your actions, so don't. Honest plans accept honest mistakes, learn from the mistake, make a new plan, then move on. Remove blame from your project so that everyone speaks freely and openly. You don't need an excuse for making a mistake you just need to learn from it.
One important communication channel omitted from the flow chart are the walls that surround your project space. Post large charts that can be read from a distance to encourage change without bullying. Post designs as Agile models on white boards or Agile documents. The walls of your projects space can communicate honestly and neutrally if you use them well.
Count how many people are on the project, now communicate like a group that size. Even a project in a huge company can communicate like a small start up among themselves. Communication efficiency drops off rapidly with increasing distance so get everyone together. Being able to see meetings and gatherings occur and eavesdrop as needed boosts communication. Hermits don’t share, communities are based on sharing and being near each other.
There is more to owning software than just paying for it. Intellectual property is only valuable if you understand it, can modify it, or reproduce it as needed. People are not disposable, they are needed to continue owning the intellectual property you are investing in. Allow everyone to talk to everyone else to avoid loosing your competitive edge. Keeping people isolated doesn't just slow down your development process, it throws your intellectual property away.
"The customer didn't know what he wanted" is a common excuse for project failure and it is invalid. The customer knows exactly what he wants; a solution to the problem at hand. If the project fails because the wrong software was built it isn't the customers who are at fault it is the developers. Developers are responsible for asking the right questions until a clear picture of the problem and a good solution is found

interactively. Make a customer part of your project team.
On a traditional project we do our analysis up front as a specified activity with an end date. The result is a project milestone called the requirements document. This document is approved by the customer as correct and complete. Now you may start building. The problem with this is that we often encode our requirements in a language no customer should be expected to learn and understand. Signing off on a document written in a language you don't understand is just as valuable as you expect. Instead sit together and talk about what you want.
I often hear people criticize Agile processes because the expert's time is way too valuable to be available. They often speak with anger and suggest customer representatives as a viable alternative. My thoughts are always the same; if the return on investment (ROI) is so low that you can't afford spending an expert's time you are solving the wrong problem.
You will also be adapting your process to your project in an iterative way. On a regular and frequent basis you will talk about your project and corporate culture to figure out how the process needs to change. These meetings are called retrospectives and are a very important part of the iterative process. Schedule a retrospective after each iteration or at least every other iteration. Ask team members what needs to be improved and what worked well. Also ask what is extra process baggage that can be eliminated.