There's no doubt about Scrum being difficult to master. But if a team has been practicing it for quite a while and if the scope for streamlining the process or improvement is little to none, what role would a Scrum Master play in such a team?
The Scrum Master is always helping the team become more agile. If the team does become agile in its true sense is the scrum master advised to quit? Or take up some other role or designation? In short, can a Scrum Master's job be "Done"?
I don't think there is a simple answer to this question. Instead, I think there are a number of different scenarios:
A team is very experienced in Scrum and rotates the Scrum Master role. They have no need for a full-time Scrum Master.
A team is very experienced in Scrum, but they still face impediments and they prefer not to be distracted, so they appreciate the Scrum Master facilitating the solutions.
A team is very experienced in Scrum, but the organisation they work in imposes a lot of external demands on their time (reporting, budgeting, etc.) and they feel the Scrum Master helps them with this so that they can remain focused on development.
A team is very experienced in Scrum, but the members of the team don't enjoy facilitating and so are happy to have a Scrum Master that performs this activity.
So my answer to your question would be: it depends on the team, the domain, the organisation and the Scrum Master. I think there are a number of possible outcomes, including:
Robert C. Martin said at one point about the Scrum Master that it:
[...] should be a temporary role, to remind people to follow the steps of the process. It's not a separate job, but something one of the team should do for a bit, then pass it on. After a while the team shouldn't need a Scrum master as they will know how to operate their process. Maybe they will forget it later and need a Scrum master again for a while.
Rotating the role between team members makes sense. Everyone gets a better understanding of Scrum, everyone shares the responsibility about their process not just one specially designated person. It makes sense. But it also doesn't.
The quote above also mentioned that:
Maybe they will forget it later and need a Scrum master again for a while.
The reality is that people tend to drift from the Scrum principles and values if this role isn't their primary one. If you are a developer most of the time, and this sprint you are designated as the Scrum Master, are you going to ignore the fact that you are a developer? Most likely you will ignore the fact that you are a now a Scrum Master.
So IMHO you always need a Scrum Master. Scrum is not something you achieve. You don't climb the Scrum mountain then stick a flag on it once you reach the top. Scrum is something that allows you to continuously improve your product, your team, your processes, and your working environment. So I think a Scrum Master's job can't really be "Done", in the same way you can't be "Done" with using Scrum.
The Scrum Master is the team's coach and facilitator. Just because the team has been using Scrum for a while and understands the core framework doesn't mean that there aren't experiments that can't be done with new techniques (which may even mean using something other than Scrum) or that there's no need for a facilitator or that impediments won't come up that the team could use some help with or that the broader organization won't need more help with interacting with agile teams or... Continuous improvement is a cornerstone of agility and Scrum, and it doesn't stop just because the team has been using Scrum for a while.
The job of a coach is never "Done". There's always something that can be improved, made better, taught, or facilitated.
Scrum master needn't be a full time role. I have worked in teams that rotated the scrum master role among different members of the development team.
The Scrum Guide says that the SM's responsibilities extend beyond the team to the wider organisation, including "Leading and coaching the organization in its Scrum adoption; Helping employees and stakeholders understand and enact Scrum". Scrum and agile are often perceived as IT deparment's thing. Scrum masters can certainly play a role in championing and educating people about agile ways of working across an organisation.
It is important for every scrum team to have someone who is thinking about whether or not the team is adhering to agile principles.
In that sense, there is always a need for a ScrumMaster - whether that is one person all the time, or the role rotates among team members.
That being said, in my experience, as a team matures, the reliance on the ScrumMaster role diminishes over time as the team finds its groove and masters the art of tweaking their processes through the retrospective process.
I disagree with the practice of teams keeping a non-developer ScrumMaster around to facilitate meetings, take notes, badger people about tickets and the like. In my experience, if you take the SM out of that role, the team operates more quickly, more smoothly and with fewer miscommunications.
The ScrumMaster's job is about more than just enforcing the process within the team, or even among the stakeholders. The ScrumMaster's biggest job is to make sure the process is working well for all involved. The team could have mastered the Scrum process, and both they and the stakeholders/product owner could be totally invested in the process and committed to making it work, and it can still fail. It's the ScrumMaster's job to avoid this possibility, whenever and wherever any problems that could derail it may arise.
One of the biggest aspects of that general role, therefore, is roadblock removal. When the team identifies a point beyond which they cannot proceed without something changing, it's the ScrumMaster's job to ensure the required change happens far enough in advance of it being an actual block on productivity that said productivity isn't affected. This change could be anything; in my experience it's usually some matter of a cap-ex, a needed hire, or other expenditure of money above the basic team cost, that everyone probably knew they'd need eventually, but didn't want to cut the check for until they absolutely had to.
It's the ScrumMaster's job in those situations to get that check cut sooner than later, and to make sure whatever's being paid for is accessible to the team ASAP, so that the team doesn't actually hit the roadblock and have to hit the brakes. Failing that, the ScrumMaster is responsible for finding a "detour"; a way through the critical path of the project that requires the least deviation from the timeline, along which the team can proceed at least for a while longer until the roadblock is cleared and the team can pick up the blocked stories.
These things happen even to the most well-oiled, highly-skilled Agile teams; that team doesn't usually have the authority to hire people, they don't cut checks for hardware stacks or cloud contracts. They certainly don't spend their days on the phone with U.S. customs to make sure the hardware security module procured in the US, that has to be in place over in Belarus by D-day or the entire system can't come online on-schedule, isn't going to be held at the port any longer than it absolutely has to while they make sure it's not subject to ITAR. As a non-specific, hypothetical example.
Very often, even the ScrumMaster doesn't have those powers. But, he has the people who do have such authority or contacts on speed dial (and if he doesn't his time is spent identifying those people and their direct lines of communication), and it's his job to make sure all the necessary people are coordinating effectively to clear the roadblock before it actually impedes team productivity.
That's no small job, usually because the ScrumMaster has very little power to make things happen himself. His primary tool is finding the proper motivation for those with the requisite authority. For check-cutting people, his main point of contact is usually the product owner and his own PM, and the motivation is simple; spend the money now, or else every day after today that you don't, 6 guys will be sitting on their thumbs at your expense on top of the money you don't want to spend. For hiring, it's usually more internal (unless the salary requires dipping into contract slack), and the motivation is similar; hire one guy with the specialized knowledge we need to negotiate this big unknown in the system architecture, or waste six dev-days on contract every day you don't.
For unrelated third parties, it gets harder, because the guy at Norfolk or Houston, that has to sign your papers before your cargo container goes on a ship, couldn't possibly care less how much his failure to do so will cost your firm and your client. The ScrumMaster in these cases usually has to find some alternate motivation, or alternately find someone who knows that alternate motivation. Could be a personal friendly relationship with the customs agent themselves, where a little schmoozing gets the paperwork bumped up to the top priority. Could be a personal friendly relationship with your Senator, who has a personal friendly relationship with the House Rep of that port's district, who has a friendly personal relationship with union leaders and/or port authority management that can issue the appropriate Word From On High.
Anyway, back to the question, this is the ScrumMaster's overall job; not only to make sure the invested parties in the project follow Agile, but to make sure Agile works for those parties, even when rubbing up against un-Agile forces of the real world. For a well-oiled team with committed stakeholders, most of the ScrumMaster's job will involve the real world, which is honestly a much bigger and harder part of the job than getting the team to do what they're supposed to in the process.
Well, I think the most Agile answer would be: Ask the Team if they still need a Scrum Master. They are best suited for judging the value he adds.
I also tend to observe that a job description as "Scrum Master" is often including more than the role "Scrum Master" in the narrow sense of Scrum. Even Kanban teams might have someone called "Scrum Master". While this can be a case of overusing terms as a sign of Fake Agile culture, I think it also indicates that many "Scrum Masters" have qualifications beyond Scrum ceremonies.
So I think that more often than not, even if the role "Scrum Master" might get obsolete, the person called "Scrum Master" can add a lot of value to an Agile team. But I also see nothing wrong in a Scrum Master leaving a company after s/he and the Team decide that his/her job is "done".
