How to rollout Scrum – a summary

In the prior post, I noted that Tom Mellor had a basic objection to this question (How to roll out Scrum). Which was, and I hope I do not misstate it too much, don’t try to roll out 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 roll out Scrum. Albeit, it is hard to ever know in advance if they really want it.  (It is only barely correlated to whether they say they do or don’t want it.)  Still, we take action and then we inspect results. So, below is my comment in that list about that.

____________________________________

Let me go back to the main thesis or question.

Let’s say you are in a group of 200 people (say, a software 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, or at least the leader does.
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.
   • identify a speed of roll out (e.g, X teams per week or month)
   • identify the new Scrum teams and their work
   • train the teams in Scrum. (This might include a definition of ‘barely acceptable Scrum’ in your context. Vaguely similar to the Definition of Done idea.)
   • get coaches for the teams, and maybe others
   • train the top managers of this group (not so easy)
   • train the other managers (probably harder)
   • 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.)
   • help the middle-managers understand their new job/jobs
   • instill a continuous improvement culture and specific values, principles and practices around that (I like the teams doing an A3 every other Sprint, as one example. Relatively soon, this includes more training.)
   • 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.

_______________________________________

Again, your comments are welcome.

 

 

« « Is there hope? || Dear Rob – 2 » »