Chinese whispers on Scrum roles

Few days ago, I attended the 2-day Martine Devos' Certified Scrum Master, Estimation & Planning Class at Skills Matter. I had the privilege of meeting and learning from Martine Devos, one of the best Scrum trainer in Europe. This also gave me the opportunity to discuss many aspects of the Scrum process.

Becoming a Certified ScrumMaster® shouldn’t be the goal of attending the course, because certifications don’t make you a real Scrum Master. To become a Scrum Master you have to put the Scrum theory into practice.

Scrum is not a silver bullet, it is a framework with a small set of practices that will help produce better value to the user with faster feedback and greater team cohesion. Adopting Scrum will require investments: the whole company has to learn new practices, principles, values. Being Agile is about recognising weaknesses and constantly learning from them, according to Ken Schwaber:

"Scrum is [..] constantly pointing out your shortcomings."

Deciding to change means that both stakeholders and the team must respect 3 essential Scrum aspects:

ROLES

• Development Team
• Product Owner
• Scrum Master

CEREMONIES

• Sprint Planning
• Sprint Review
• Sprint Retrospective
• Daily Meeting

ARTIFACTS

• Product Backlog
• Sprint Backlog
• Release increment

These aspects must be present when a company decides to do Scrum. How you facilitate a Sprint Planning session, and the technique you use for creating a Product Backlog (with User Stories, User Journeys, Storyboards, Scenarios etc) can be chosen according to circumstances and needs.

In this blog post, I’m not going to write about Scrum ceremonies and artifacts. I want to clarify the Scrum roles in order to get rid of the fallacies that have been established since Scrum became popular.

The Scrum Master is not the Team boss

The name “Scrum Master” has created too many misunderstandings. The word “Master” attracts people who want to be boss, leader, manager. But the word Master doesn’t have those meanings in this context. Here, the word Master stands for Mastery: the Scrum Master understands Scrum principles, values, and practices, and helps the team to become more efficient at delivering quality and valuable software. But all of that couldn’t be possible if the Scrum Master doesn’t involve the whole organisation in this learning process.

The most important lesson that Martine Devos taught the class during the two days has been that, the Scrum Master’s role has nothing to do with activities like: controlling, managing, deciding, directing, committing etc. There are no hierarchies in a Scrum Team: the Scrum Master, the Developers and the Product Owner are peers—they are members of the same team. The Scrum Master is not automatically a Leader and the Product Owner is not a Manager. First of all, a Scrum Master is a facilitator that ensures the team communicates constantly and efficiently. The Scrum Master makes sure that the team works together and recognises new opportunities of improving the way the product is built. According to Martine Devos,

"A good Scrum Master doesn’t read books or article on Scrum. A good Scrum Master is someone who reads books on facilitation."

The Product Owner is not a manager

Amongst other things, the Product Owner is a facilitator as well. He/She facilitates the communication between business people and technical people in order to ensure that everyone is involved in discussions that will lead to building products aligned with users’ needs and expectations. The Product Owner has the responsibility of taking the priority decision about the product but ensures that it in agreement with the rest of the team.

The Development Team isn't made of Software Developers only

The word “Development” used to indicate the Development Team, has led to too many misunderstandings as well. The word Development doesn’t stand for a team made of Software Developers. The Developers Team is a cross-functional team composed of Software Crafts(wo)men, UX Designer, Analysts, Testers, etc. A cross-functional team has everything needed to create a successful project.

Conclusion

In a company, each role has specific responsibilities but everyone is also responsible of the success of a product. Building a successful product is about: communicating frequently, working together, respecting each others, and trusting team members’ skills and experience. Hierarchies and the culture of fear can only generate communication barriers and lack of motivation.

I suggest you watch Henrik Kniberg's video about Spotify Engineering Culture. I hope it inspires you as it did me.

I’ll dedicate my next blog post to Scrum Ceremonies. Feel free to contact me for question about the Certified Scrum Master course, Sketchnoting, the Spotify video and more.