Traditional teamwork has the project manager controlling everything. The manager is given responsibility and authority over all decisions and plans. If you can only trust one person with power then this makes sense. But, if you have a team of good people it becomes inefficient and inhibits working at your full potential. Don't bottle neck decisions with a single authority. Change from one person controlling everything to empowering the entire team.
Who is responsible, who has authority? Everyone. The most important thing on a project is good leadership; the least important thing is who leads. Leadership and management are two very different things. Leadership is about seeing a problem then getting people together to solve it. Any team member who knows enough to foresee a problem also knows enough to lead the solution. It is your responsibility to do so.
It may be counter intuitive, but a team that is calm and confident about their work is very decisive without a single person as boss. There are plenty of jokes about committees being unable to produce a good design. Bad designs can happen to any team if the product vision isn't strong and well voiced. That is the responsibility of the customer/product owner.
Being the customer on an Agile project isn't easy. You will find yourself almost constantly in a leadership role. You must be actively involved in most discussions to make sure your vision is followed. You will often be put in the unenviable position of breaking hotly debated deadlocked discussions. You will decide when the team's code is ready for deployment. The most difficult part will be setting priorities and making the hard decision of what will get done and what won't. This is a far different role from signing the front page of a requirements specification.
If your customer is too valuable to spend time with your software team then maybe you are building the wrong software. Ask the customer what would be valuable and exciting enough to make him want to be there with the team.
The role of developer/team member includes programmers, architects, DBAs, testers, all of us digital construction workers. Our responsibilities now include deciding how to get organized and what to do next. We will accept the responsibility of leading ourselves and looking for potential problems while mitigating risks. This is different than just writing code as directed.
The manager/scrum master will have many new responsibilities. The biggest change is just watching the team interact and being there in the middle of it. If relationships are broken then the manager must repair them. If the customer isn't leading with a consistent product vision the manager must act. An unsuitable customer can lead a team in circles and get nothing done. A developer that breaks the process can slow the entire project down. Replacing customers or

developers is a hard choice and must be done wisely and kindly.
People develop emotional attachments to their projects. Agile projects are even worse because we work together tightly. Some people will fear getting hurt if a project fails and try to sever their emotions or leave before they are hurt. It can seem like people are trying to make the project fail. I call these types of bad behavior "escape velocity." Managers might wonder why team members would want to hurt the project and consider replacing them. That is the wrong point of view; wonder instead why the project makes people afraid they will be hurt, then fix the project.
One management responsibility that doesn't change is removing obstacles to success. What does change is that you don't get to decide what is an obstacle and what must be accepted as non-negotiable. Your team tells you everyday at the daily stand up/scrum meeting and you must act to the best of your abilities.
The manager also decides if the team should be refocused during an iteration/sprint. The manager has the authority to schedule planning meetings (or abnormal sprint termination) and must do so wisely. Too many planning meetings can create chaos and nothing will get done, too few planning meetings doesn't provide the customer opportunities to steer the project. Scrum recommends no changes during the 30 day sprint. Extreme Programming (XP) recommends short iterations of one week so an opportunity to change directions is never more than a few days away. You must listen to why a mid-iteration change is needed and decide.
Everyone needs to get used to distributed leadership. The people most involved with a decision make it when they face it. There is some evidence from the Lean Development people that putting off decisions till the latest responsible moment when you know the most about the impact is a good idea. I prefer to simply say that if you know enough to see a decision must be made and believe you know most of the consequences then you know enough to make it. If you find it wasn't a good decision later just estimate the cost of going back to it and let the team negotiate with the customer.
Highly productive self organizing teams are not easy they require discipline. Good leadership isn't doing what ever you want when ever you want. The team member with the least discipline has the most control by simply not following the process. You must set and meet team expectations at all times. Other team members must be able to trust you and know what to expect from you.
There will be decisions to make and they don't always get made well. Decisions being made by whoever gets there first can cause significant amounts of disharmony. Accept that decisions will need to be made. Accept that you

will not make all of them. Your responsibility as an empowered team member is to be aware of discussions going on that you feel strongly about. You are responsible for joining in, and contributing without prompting.
One thing that can expedite team empowerment is to remove blame. Some of your team will hesitate to make important decisions if they feel someone else will bully them over it later. In some companies being late with someone else to blame is just as good as being on time. Eliminate blame as acceptable by making it clear no one wants to hear it.
One of the biggest misunderstandings of team empowerment is that teams just become empowered when you announce Agility has arrived. The team starts out following a set of rules designed to set expectations between team members. Most people don't like rules because rules usually constrain. An Agile team sets rules to become free. Create simple rules focused on defining the interfaces between team members. A good example is the daily stand up/scrum meeting. A rule to have it in the same place at the same time for no more than 15 minutes actually frees up time for other things.
Eventually you will feel the ebb and flood of leadership. You learn to follow reluctant leaders because you know they see something you overlooked. You get organized around problems without prompting. You will understand team empowerment enough to mold your process to suit your project and company easily.
If it seems like chaos could result you are correct, unless you also change the way you communicate. With a single control point you only need a single completely informed person. Team members can go months without speaking to each other so long as one person knows everything and controls everything. Unfortunately even with smaller projects this command and control model breaks down quickly. You must eliminate barriers to communication for Agile to work. No one works alone anymore.