'How' to rollout Scrum - a summary

In the prior post, I noted that Tom Mellor had a basic objection to this question (How to rollout Scrum). Which was, and I hope I do not misstate it too much, don't try to rollout something to an organization that does not really want it.

He used the other pig metaphor, which I liked. He said: It will be like trying to teach a pig to sing. It will frustrate you and annoy the pig. See here.

But I think there are times when it does makes sense to rollout Scrum. Albeit, it is hard to ever know if they really want it. Still, we take action and then we inspect results. So, below is my comment in that list about that.

***quote***

Let me go back to the main thesis or question.

Let's say you are in a group of 200 people (say, a SW dev group). Let's say the group has experimented with Scrum and generally likes it. Let's say at least some 'business' people like it (they are outside this group, basically its 'customers' in some sense). Let's say you have convinced the head of the Dev group that rolling it out is a good idea.

What are the next action steps?

1. To Tom's point, it would appear that the org (the 200 people at least) mostly want this change.

2. I would actually do something to assess how much the group really wants the change and what is it exactly they want. (With a smile and some tears: Often they just want no more documentation and no more planning, let's just start writing code and complaining. Meaning: They want their own myth about agile.) An Open Space might do that trick. But there are other methods. BTW, it is not necessary that everyone like it.

3. Assuming things are still positive. Then the roll-out needs a few things. The scrum community argues about their relative priority, but mainly these.

a. identify a speed of rollout (eg, X teams per week or month)
b. identify the new Scrum teams and their work
c. train the teams in Scrum. This might include a definition of 'barely acceptable Scrum' in your context. Not unlike a Definition of Done.
d. get coaches for the teams.
e. train the top managers (of this group). (not so easy)
f. train the other managers. (probably harder)
g. set up what I call an 'Impediment Removal Team' of managers. (Other books give this team a different name. Cf Schwaber, Cohn and others.) As a Scrum team, or semi-Scrum team. Their product backlog is the main/big impediments overall. Sooner or later 'adoption issues' will be added to that list.
h. help the middle-managers understand their new job/jobs.
i. instill a continuous improvement culture and specific values, principles and practices around that (I like the teams doing an A3 every Sprint, as one example.) Relatively soon, this includes more training.
j. start attacking Technical Debt ASAP.

I say 'training' above. What I really mean is an event that almost viscerally changes them. At least, that is what you want. We call it training to get them to come.

A fairly typical list. Lots more to add, of course.

***unquote***

Again, your comments are welcome.