Have you ever played Chess? Chess has 6 distinct roles in the game. A king, queen, bishop, knight, rook, and pawn. Each player has a certain amount of those pieces, but in the end, the pieces themselves have a particular way they can move on the chessboard. Collectively, they form the strategy for how to win the game and thus each one has its own strengths and weaknesses that are their own. Ironically, if we were to sit down and play a game of Chess, we either can choose to follow the rules, or not. If I said, "I don't like how the knight has to move in this funky L shaped pattern, so my knight is going to move like a bishop", then we aren't playing Chess anymore.
Scrum has a set of roles prescribed in the a non-prescriptive framework. It also prescribes 4 ceremonies and common activities that should be taking place at the team's discretion. I spend a lot of my career educating and coaching teams on how to effectively use Scrum in their culture/environment. Each organization is like a person; they have their own personality and thus we simply cannot say that each Scrum team across the globe works the same. They share some values, principles, and the framework, but have much freedom in the way they adapt Scrum to work for them. That is Scrum's power. However, there are some teams that actually try to affect the rules of the game to where they might not be playing Scrum anymore. There are also many organizations that create their own way of working that is fundamentally not like anything out in the industry; great for them (if it works). Our goal, in the end, is to produce great products for our customers, not simply follow some process for the sake of following process.
I could go on and on about the practical ways to practice Scrum, but we will focus only on roles this time. Scrum has 3 roles; Product Owner, ScrumMaster, and Development Team. Naturally there are stakeholders as well, but let's focus on the people doing the work. When an organization is transitioning from X process (or no process) to Scrum, the first thing they encounter is how to organize themselves appropriately. Who will be our Product Owner? Who will be on the Development Team? Who will be our ScrumMaster? All great questions to ask, but more often than not, the first 2 roles are more easily identifiable than the 3rd. Who is our Product Owner? Usually there is someone already working in that capacity in some form or fashion. While it might be difficult to discern who might do it in the end, it is usually less difficult to point to the group of people who have the skills to do it for the teams. Who is on our Development Team? Well, those people likely already exist as well, we just need to organize them into cross-functional / self-organizing teams (developers, testers, database developers, UX people, etc...). Then we hit that 3rd role. Who will be our ScrumMaster?
Hmmm...this one is a bit tougher because likely your organization does not already have someone who is actually working in the capacity of what a ScrumMaster does for the team. The first place we usually look to is the project management team. "Hey these people already do some adminsitrative function over the work, they manage the team, etc...". Let's just turn our project managers into the ScrumMasters. This often becomes one of the biggest mistakes we can make. A ScrumMaster is NOT a project manager. They are a coach. Very rarely does the organization have someone they can point to currently in the organization that is trying to make everyone better. The organization is more about managing than it is leading, educating, and focusing on improvement. A ScrumMaster works ON the organization, not IN it.
Who do you have that currently does that? Probably no one. A ScrumMaster coaches the entire organization on how to foster agile values and principles and pushes on the teams when we tend to step outside of the bounds of what the principles suggest. The job of a ScrumMaster is a bit non-tangible. I get questions all the time "What does the ScrumMaster do each and every day"? My answer? I don't know. Each team and organization has different needs. I can tell you the kinds of questions they should be asking themselves that drive tangible behaviors, but its not set in stone and the same for each team.
The ScrumMaster is helping to create professional teams. What separates a professional from amateur? (yes, they get paid, but why?) A professional doesn't need to be told how to play the game or the rules of play. Think of your favorite sports team. Do you think their coach brings the team over between play and describes the rules of the game and fundamentals of how to dribble a basketball, kick a soccer ball, etc...? No! They bring them over to help them on strategy, where is the other team beating us, what do we need to work on, etc...Now if your team is a 3rd grade team, you as a coach might spend more time on the fundamentals. The same is true for a Scrum Team. New teams need a bit more guidance and direction on the structure and fundamentals of play. Our job however is to help the team become successful and see all of their pains without us always having to point them out. We can then focus our attention on the organization. I find there is actually more work needed on organizational change to foster an agile culture than the time it takes to get a team fully functional and productive.
So, if the team gets good and professional, we no longer need a ScrumMaster right? WRONG! Think about your professional sports team...do we ever get so good we don't need the coach anymore? They are always there observing and helping to see how the teams are progressing from the sideline. If you are in the game, its a lot harder to see how the team works together. What does a ScrumMaster do each and every day? I don't know...what does your professional team head coach do every day? Is it a set pattern or does their work list get generated off the needs of the team? Each and every day can be a bit different.
The point? Do not dilute the 3 Scrum Roles by assuming that no one of them is a full-time job. Each one of them have their responsibilities and each one of them is a full-time job (if not more). Too often we make the first mistake of putting the wrong people in the role or we simply share the role because we can't see the value of having a full-time dedicated person in that role. Sure their are exceptions, you have to make decisions that are economical for the organization and we can certainly find situations where sharing the role or having people facilitate multiple teams are necessary. Try to make that our last resort though. Fight to keep the roles independent and full-time to that role. Focus is a value of Scrum, yet we tend to violate that out of the gate by diluting a person's ability to do their best job by giving them multiple jobs to do for the teams. ScrumMasters are helping all involved play better together. That's the difference in "doing agile" vs. "beging agile".
