In the more traditional projects that I've worked on, the project manager (and, on larger projects, there might be associate/deputy/assistant project managers should one person be unavailable) is the person responsible for communicating with the customer, receiving project health and status updates, determining scheduling and budgeting, managing the process, ensuring the team has what they need to complete tasks, and so on.
In Scrum, however, these responsibilities are split between the Product Owner and the ScrumMaster. The Product Owner is the voice of the customer. They interact directly with the customer, create user stories, organize and prioritize the product backlog, and other user/customer facing issues. The ScrumMaster handles the process, overseeing meetings (including estimation and planning), removing impediments, and monitoring the overall health of the project, making adjustments as needed.
I've read in multiple sources, including Wikipedia, that the role of ScrumMaster and Product Owner should be held by two different people. I've not only read about, but worked on successful "traditional" style projects where the activities of both were handled by a single individual. In fact, it makes more sense for one to three people to be responsible for handling project (including human resources/staffing) and process level tasks, as they often go hand-in-hand. Process changes have an impact on scheduling, budgeting, quality, and other project-level goals, and project changes have an impact on process.
Why does Scrum call for isolating these activities into two roles? What advantages does this actually provide? Has anyone been on a successful Scrum project where the Product Owner and ScrumMaster were the same individual?
Best Answer
They can (and often are) combined and done by a single person (there is no rule against this (its scrum after all)).
BUT you you need to balance the difference responsibility carefully as the two roles have competing and agendas (and it takes a special person to be able to do both simultaneously). I have seen many try but few pull it off over a long period of time (its a stressful position).
To be the SM you do need more technical knowledge than the PO (as you will be helping organize the development team). It takes detailed knowledge of the product to be able to pull things from the product backlog into the spring backlog (sometimes you just can't pull the top 'n' items as this may be counterproductive).
The PO requires more understanding of the user end of the equation than them SM. This does not need to be as technical but does require knowledge of how the product is going to be used in the real world and the direction the customer wants to take the product.
If you can find a person that can do both roles then I see no reason to prevent this.
Problems may arise when the PO is being pulled by the customer in one direction that is causing significant strife to the developers (because they need to build some other infrastructure first). The SM job is not to follow the whims of the customer but to protect the developers from their whims. Pulling this off objectively is hard.