This week's book giveaway is in the Java in General forum. We're giving away four copies of 97 Things Every Java Programmer Should Know and have Kevlin Henney & Trisha Gee on-line! See this thread for details.
This thread is a bit dated but I'll give an answer anyway for the benefit of any lurkers out there.
The issue of roles and responsibilities in Scrum vs. HR hierarchy can be a sticky one to resolve. The best approach I have seen is to separate the Scrum team and roles from the HR-related hierarchy. That is, they should be fairly independent of each other. It's mostly a bad idea to make a functional/line manager the Scrum Master on a team comprised mostly of his/her direct or indirect reports. I think there is a better chance of forming self-organized and highly collaborative teams when the Scrum Master does not have a direct reporting line with any of the other Scrum team members. Likewise with other members of the team to each other. Of course, you'll often still have to empower some individuals to make high-level decisions for the team and give enough authority to the Scrum Master so that he/she can remove any obstacles to the team's progress.
The HR hierarchy concern usually has to do with performance evaluations, bonuses, and promotions. Individual performance evaluations should factor in feedback from other members of the Scrum team, the product owner, and customers. Many companies are also starting to factor in a team-level performance score to determine baselines for bonuses. This is seen as a way to encourage team behavior, where the team succeeds or fails as a single unit. It can help discourage the "Well, I got my stuff done, it's the other guys on the team that messed up." type of mentality and foster the practice known as Collective Ownership.
When you have a high-performing Scrum team, transparency of their work and success/failure is high so functional/line managers should be able to see just by looking at the information radiators and metrics (e.g. velocity, burn-down rates, running tested feature count, code coverage, commit rates, etc.) gathered from the releases and iterations just how the teams and individuals are doing. This should provide enough information for a performance evaluation and review.
Hope this helps.
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck