Scrum has 3 primary roles of Product Owner, Scrum Master and delivery/development team member. However, I’ve run into “Scrum” implementations that are using roles such as “Lead Developer” or “Lead Business Analyst”. It’s bad enough you’ve created “new” roles for Scrum but when you use titles that include “Lead” it’s reflecting a lack of commitment to the Scrum principles and you’re using a command and control process that you’re now calling Scrum.
Other signs of a command and control process is when you have Product Owners who are interacting directly with your delivery team. Just last week I spoke to a “Product Owner” who was saying how the Scrum process was not “taking hold” at his company and the team had failed to “self-organize” and were not engaged. He went on to say that in his weekly one on one status meetings with delivery team members his team members were not happy with the “new” process. After a longer discussion, he said that prior to the Scrum implementation he was the Project Manager utilizing a traditional waterfall approach.
In this case it was evident that the role titles had changed but the process had not. The Product Owner should not be meeting on a regular basis with delivery team members to get status updates on where they are with their work. That responsibility lies with the team and progress is readily available to the Product Owner on a daily basis through burn down/up charts.