A lot of folks come over to Scrum after spending a considerable amount of their careers navigating the possibilities present in a Waterfall model. At its fundamental levels, the roles associated with Waterfall projects are:
- Project Manager
- Business Analyst
- Development Resources
- QA Resources
Within Scrum, there are 3 roles:
- Scrum Master
- Product Owner
- Team Members
In an attempt to map from known Waterfall roles into the Scrum roles, large organizations would normally match these up as:
- Project Manager = Scrum Master
- Business Analyst = Product Owner
- Development Resources = Team Member
- QA Resources = Team that does isolated testing during the QA window
There are multiple problems with mapping roles in this manner, and I believe this errant mapping is a major impediment to existing organizations succeeding within a Scrum model. And it usually causes the model to quickly breakdown or get thrown away.
My previous blog discussed the concept that the Scrum Master should be a servant leader promoted from within the ranks of the development resources. This allows the Scrum Master to perform user story development in the trenches with their team while allowing them to guide the team through the Scrum process. (Short answer: A Scrum Master is a mix of a Technical Lead and a Project Manager, but much more the former than the latter.)
The Product Owner is often overlooked in the Scrum methodology, but the importance of this role must be recognized. This is the person who authors the user stories, ensures they are ready for consumption for the team, establishes the priorities of these stories, ensures they are understood by the team, and coordinates all business related aspects of managing the product. As such, they are a cross between a Project Manager and a Business Analyst, with much more emphasis on the Business Analyst role. (Important side note: this is one person, rather than a group of people. The team needs to interact with a single point of reference that is able to merge together multiple opinions/priorities/requirements. One person needs to navigate this for the team to allow them to focus on delivering functionality.)
Many times, I see that the Product Owner role isn’t clearly defined or the person serving this role isn’t invested enough in the team. Oftentimes this takes the form of a single person fulfilling the role of enforcing the methodology (Scrum Master) and managing the backlog (Product Owner). This person is often known as a Project Manger during the company’s Waterfall days. This can easily lead to a cycle where the team is not self directed and not empowered to solve their own problems.
Other times, rather than training personnel to fulfill the roles that are needed, folks from either the Project Manager or Business Analyst roles feel squeezed out by a move to Scrum. This doesn’t even take into account the difference between Waterfall often being a project-related discipline, while Scrum IS a product-related discipline… but I digress into a topic for a future blog.
Who are your Product Owners? How invested are they in a single team? And what training have they been given to ensure a smoother transition into making Scrum an effective choice for your organization?