Why Scrum Masters should drive the change to a company?
Many companies which are trying to implement scrum, come to a point that these agile activities and principles should be transferred to the rest of the company.
If we assume that Scrum Masters understand the role to its core, then there are no better candidates to choose for transferring the change to the rest company's departments. Scrum Masters think (or should think) out of the box, sometimes even out from the scrum framework box.
The reason is that scrum framework leaves a lot of space to deal with the various problems a team faces during development. Apart from that, many problems come from other departments which does not understand what these teams are doing and they feel that agile processes are not for them.
Well it turns out that having just scrum teams being the only agile part of a company leads to a dead end. So when the time comes, Scrum Masters should be the persons who will detect problems in the rest of the company starting with those which affect mostly the teams.
What backup Scrum Masters could have?
A scrum coach of course. Most of the times a scrum coach is the first choice of a company that wants to move towards Agile and specifically the Scrum methodology. Initially the role of the coach is to give his knowledge and experience to the people who will be involved to the transition.
Most of the times this is not just the Scrum teams. The coach should prepare the people who will be around the teams, to accept and understand the new way of working. Also he must wisely choose the Scrum Masters with the goal that these people will be a backup for him too as they get more and more into the Agile principles and best practices.
So the truth is that the coach is surely a backup to the Scrum masters on their baby steps. But after a while, a strong team containing the scrum masters and the coach should be established to drive the change to the rest of the company.
It becomes obvious that one person (the coach) cannot affect big companies because there are many hidden issues in various departments, that only people like Scrum Masters who probably interact with these departments, can reveal them and probably solve them. Remember that a Scrum Master removes impediments and impediments most of the time are related to interactions between the Team and other people/departments.
Escalating the problems to the coach may lead to overload and lose the ultimate goal which is the successful transition and the continues improvement.
The role of the coach is important not only for training the people to scrum, but for a reference inside the company which points to a person who knows what should be done. From the other hand the coach needs the Scrum masters to backup him when some hard moments will come. Since Scrum Masters are practicing the Scrum methodology and try to remove impediments, they are "doomed" to understand the reasons behind the process. So again they are the best followers of the coach.
No one could help better when the time comes to defeat the "Enemy at the gates" who will try pull down people to the old "bad" habits of the company.
The team of Scrum Masters and their backlog
So a team must be created after the Scrum Master are fully understand the principles of Agile. This team should have their own kind of backlog and create "Stories" which in fact will be actions that will promote Agility to the rest of the company. For example they could have "Features" like:
These could be close to the ADAPT activities found in Mike Cohns book "Succeeding with Agile"
Awareness that the current process is not delivering acceptable results
Desire to adopt Scrum as a way to address current problems
Ability to succeed with ScrumPromotion of Scrum through sharing experiences so that we remember and others can see our successes
Transfer of the implications of using Scrum throughout the company
Cohn does a very good explanation for each activity and what means for a company. So having them as a basic pillars you could design backlog "Features" which by executing their "Stories" will help the company to change.
Transparency for example could have user stories like:
As an "agile promoter" I want to establish a meeting between the person in the X department and the persons to the Y department in order to promote transparency between their activities so the...blah blah
The Retrospective "feature" could have stories like:
As an "agile promoter" I want to establish a Retrospective between the members of the X department and the Y department in order to find and solve the repeated problems they faced the last Z months.
The Promotion "feature" could have stories like:
As an "agile promoter" I want to invite people from other departments to the Scrum Review meetings in order to see with their own eyes that Done software is delivered in each Sprint.
The Transfer "feature" could have stories like:
As an "agile promoter" I want to organize a training for Test Driven Development in order to train the teams to use that practice.
So having a backlog of this kind immediately puts a scope like the scope of a Software Project. You keep a live list with activities that will drive the change. Even if scrum masters cannot keep iterations to execute these stories, the stories will be there to remind them what needs to be done.