A few days ago, I attended the two-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 trainers in Europe. This also gave me the opportunity to discuss many aspects of the Scrum process.
A common sight during the Daily Standup.
You may also like: How to Make Scrum Fail
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, and values. Being Agile is about recognizing weaknesses and constantly learning from them. According to Ken Schwaber:
“Scrum is like your mother-in-law. It’s constantly pointing out your shortcomings.”
Deciding to change means that both stakeholders and the team must respect three essential Scrum aspects:
- Development Team
- Product Owner
- Scrum Master
- Sprint Planning
- Sprint Review
- Sprint Retrospective
- Daily Meeting
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 isn’t possible if the Scrum Master doesn’t involve the whole organization in this learning process.
The most important lesson that Martine Devos taught the class during the two days was that the Scrum Master’s role has nothing to do with activities like controlling, managing, deciding, directing, or committing. 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 recognizes new opportunities for improving the way the product is built. According to Martine Devos,
“A good Scrum Master doesn’t read books or articles 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 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.
In a company, each role has specific responsibilities but everyone is also responsible for the success of a product. Building a successful product is about communicating frequently, working together, respecting each other, and trusting team members’ skills and experience. Hierarchies and the culture of fear can only generate communication barriers and a lack of motivation.
Article originally posted August 2016