One of the most challenging situations involving adopting agile is when doing so in a software shop that has several specialized groups already in place forming silos: development, quality assurance (QA), business analysts (BA), software configuration management (SCM), documentation, architecture, database admin (DBA), and user experience (UX). These shops may or may not have fixed (non-negotiable) delivery dates with a very tight schedule, developing either commercial products or turnkey solutions for customers. The goal is to take these silos and form a cohesive team while delivering useful software by the required date.
By using Scrum as the baseline methodology, the goal can be achieved in a way that will help the transition from the old, silo-oriented organization to the new, team-oriented organization.
It is critical to map the three most crucial Scrum roles—product owner, ScrumMaster, and the team—to the traditional organization in a way that doesn’t feel too threatening to the current managers.
Given the responsibilities of the product owner, it is quite natural for a member of the business analysts group to take on this role, as they are the ones already generating the requirements. For complex projects where multiple BA members are needed to gather the requirements, one BA member must be selected as the “voice” of the group and act as the product owner for the team. This BA member will be responsible for maintaining a ranked backlog for the team to work on.
It can be tempting to assign this role to the BA manager or supervisor. This would be a mistake, as product owners must focus entirely on the product without the distractions of the group dynamics, such as tracking and reporting, sick leaves, vacation, conflict resolution, etc.
It has been common for project managers to be repurposed as ScrumMasters. This is a good idea as long as they have received the proper training and embraced agile. You get expertise on the inner workings of the company and knowledge of the team members for free.