Do's and Don'ts for Scrum Roles

Background

10+ years as a software developer and it has been a journey to collecting experiences and unforgettable memories. Over this course of time, one thing that never ended was the hunt for the best software development Process/Model. Company, Teams and individual had to spent significant time and efforts to identify the best model; researching, understanding and implementing the principles of that model. Scrum is one of such model. It has specific roles like ScrumMaster, ProductOwner, Scrum Team and Stakeholders. While the roles were designed to do their specific jobs, if you don't stick with your own responsibilities, it leads to conflict, confusion and ownership problem. I have faced this problem multiple times.

What I have seen

Spent 5 years in a US based company when Agile concepts were at it's early days and the company decided to switch from waterfall model to the Scrum framework.  It was good to learn Agile philosophies for the first time; roles like ScrumMaster, Product owner did their job quite well; scrum cultures like Daily standup, Sprint review and retrospective solved the problems quickly. Till this day, I feel that team had the best understanding of every role. Things I liked about this team are : -

• Product owner was only concerned about product values and features. Had no role controlling sprints, team and release dates.
• ScrumMaster handled the sprint progress, scrum cultures and focused on removing any obstacles.
• Internal/External stakeholders participated only during Sprint demo. They decide to accept or not accept the features. Did not influence how Scrum team did their work.
• Team focused on actual works.

Only thing I felt lacking was Team's involvement in the decision making and ownership. It was indeed a challenge to figure out best process for 350 software engineers when they had separate team and unique project to work on.

Another 4 years in an European company where every individual proudly chanted that they are doing Agile. Few of us thought completely opposite. I felt it was less than 50% agile and not sure what rest of it was. There were many problems which were against Agile philosophy like long release cycle, strict deadlines, lack of automation, repetitive testing and more. But, in this article, we will discuss only about the problems with roles.

• Product owner participated in technical discussions which I believe is the worst thing to do. While it might sound as good thing but it has severe damage on other areas. It resulted in very long meetings, meetings not conducted on time due to absence of PO, PO could not give enough time for features, no proper sprint and product backlog, no prioritization.
• PO also spent time on release dates, project estimations, resource planning and basically everything.
• Scrum team didn't have much ownership of how they worked, how to make sprint fun, customize things.
• Stakeholder influenced technical decisions, made uninvited and unpopular changes. I have seen this issue happening most when stakeholder has a technical background and they think they can challenge the implementation details.
• There were retrospective sessions but actions were not implemented. The bigger part of the problem was with the organization environment. The Technical head was not people friendly, not open to feedback, didn't had mindset of listening to others and was mostly one directional. It didn't favored the core idea of Scrum i.e. "continuous improvement and openness".

Currently working in another company and collecting the good and the bad ones. All three companies share the Scrum Framework and more or less, they face challenges with role conflicts. One thing I realized was it depends upon the Technical head how the overall culture of an organization is driven. The bottom up approach is very difficult in my opinion unless the company is very open to suggestions and feedback. If the Technical head thinks stakeholders, PO can also contribute to technical solutions then it's hard to change, if he thinks a year long release is also good then it stays like that, if he thinks product should only be designed by the UX/UI person then it is hard to change.

So the main idea is the person who drives the decision should have good understanding of the core values and principles. Sometimes you have to make adjustments as per your need but it is more important to listen to your team and take their feedback. It is more about making rationale decisions than following some Technical Gurus or what forums has to say. Forums and Technical Gurus can say about their teams and their situations but they don't know about your team and your situation. It is a great responsibility to intelligently decide when to copy things blindly from internet and when to filter them out.
The other fact is though the final call to any decision is in your boss's hand, however the result will show if the decision he made was good or bad.

Below are the few guideline for Scrum roles

Product Owner

Dos

• Build product and sprint backlog that provides values to customer.
• Be clear on feature priority and communicate to team.
• Be contact person to the customers or stakeholders.

Don'ts

• Create confusion in the team about the product vision.
• Control resources.
• Give deadlines.

Scrum Master

Dos

• Facilitate the daily works of individual, team, resolve any obstacles.
• Monitor the sprint progress, keep everybody on track.
• Look for ways to improve process, team collaboration and result.

Don'ts

• Can suggest and give ideas but don't write requirements.
• Control resource.
• Create requirements

Dev Team

Dos

• Write clean, quality codes. Automation and documentation.
• Take ownership of codes.
• Identify team capacity and maintain balance of tasks

Don'ts

• Discuss on requirements but don't write requirements
• Prioritize

Stakeholders

Dos

• Build good relationship with customers.
• Provide clear organization vision.
• Delegate responsibilities

Don'ts

• Make assumptions on dev's work. Controlling technical discussions.
• Micromanage

These Do's and Don'ts are the core guidelines for Scrum roles which I believe helps to establish trust within the team. It maintains the clarity about the responsibilities, motivates team to take ownership, creates less confusion and work together.