Scrum Roles — A pragmatic vision

All facts below were taken from my own experience, feel free to leave me any comments or drop me a message. I will divide this article in 3 sections, one for each team component. Each of them need to find its own path for moving from good to great. I´ve seen many cases where the company wants to implement Scrum/Agile but in fact, they are just playing with roles and cool names, but the job itself remains stucked with the traditional models or some weird fusions — “Water-Scrum-Fall”.

The Dev Team.

As every single team, they need to pass through all phases until get into the high performance stage. They need to know each other, and with time, build a strong sense of unity where swarming practices are natural and constant. When a team is being agile they are not just self-organized and cross-functional, their experience across many Sprints/Releases give them a solid rock basis to deliver value and with minor assistance. Of course, it’s not easy to achieve this stage, once external influences frequently will disturb this process. Sharing knowledge and continuously improve of technical excellence is followed by a healthy and productive small celebration moments

The Scrum Master

The Servant leader. The one who will be the team’s shield against any external disturbance that may force them to lose focus. The Scrum guardian, that should be a strong reference about how to run the Scrum and bring not only the team but also the organization to the ground when any deviations were realized. Unprepared SM’s may think themselves as a people’s manager when in fact the role is under charge the team. He or She when playing this role should know a lot about intrinsic/extrinsic motivators to keep the team health in terms of self-awareness. Is not an easy role, it requires a really good level of soft-skills and obviously should be an extreme good team player. A Scrum Master that see him/herself as something apart of the team will certainly fail.

The Product Owner

The one that shall make the strategic vision clear for the entire team. The PO will not only prioritize the backlog but also split and discard user stories working close to the team. When playing the PO role, is important to have some knowledge about the business domain. If not, go learn about the business you are working with, otherwise will be hard to write a clear and objective Acceptance Criteria for all users stories and in the worst case, to be like a customer proxy, which is really bad and completely out of we know as Scrum. The PO should say no when appropriate having in mind his function is to maximize value delivered.

Now, we may have seen many of these problems around, maybe in our company or even in our teams.
 Would be the SM responsibility to fix all these issues? I do believe that the team has the power to solve it. If the SM, PO and Dev Team have a strong and mature connection they will solve this internally, otherwise we may fall into a downward spiral, when we have members that just broke the sense of team. This is one of the worst thing that can happen within a Scrum Team.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.