In a recent article in CIO Magazine (yes, again - but the short article is not online yet for the reference) on "Deconstructing Team Dynamics", from research at the University of Pennsylvania's Wharton School, they state the following...

"Teams perform better when they share similar ideas about how they get things done...When team members think alike about how to execute a project, they are able to anticipate one another's actions and coordinate their behavior. Thus, they are likely to perform better than teams whose members have different ideas about how a project should proceed."

This is exactly the efficiency and effectiveness that I find teams gain through doing collaborative release and iteration planning sessions done in an agile context with a cross-functional team. The team plans the release together (at a high-level) through identifying, decomposing and estimating the requirements through user stories - the user's perspective. The team plans each short time-boxed iteration (one at a time) together by discussing, writing and estimating all of the tasks required to fully complete a user story identified for that iteration.

So often project definition, requirements gathering and even task creation are done by "others". Usually the director, business analyst, or key architect. This appears to make sense because we do not want to impact the teams effectiveness by wasting their time with all of the project uncertainty early in a project when their is still quite a bit of fog surrounding the project. This siloed behavior continues on into the project as various pieces of the project are assigned to individuals for further analysis, design, architecture, coding, testing or documentation.

Then provide that team with the ability to self-organize around how those tasks are completed (yes, you actually let them decide who does what). The team has ownership. The team has commitment. The team discusses its issues, dependencies, completions and impediments daily with each other. The team will out perform your expectations.

I have led projects and teams using both methods, and have personally seen the difference. It seems so obvious, but is done so infrequently.