Disneyland Scrum vs. Industrial Scrum

When I teach Scrum, I start with the idealized version of it. For all of Scrum’s famous (at least to me) simplicity, it can be quite difficult and time-consuming to explore all of the nuances and possibilities and corner cases. Over the past couple of years, I’ve begun to refer to this idealized version of Scrum as ‘Disneyland Scrum.’ In Disneyland Scrum, everything goes well. Teams self-organize. Self-organized teams have good ideas. People are excited to sit through planning and review meetings. Everything on the Product Backlog is an identifiable feature expressed as a user story. Management “gets it” and makes no unfair demands on the team. Disneyland Scrum works great!

I used to make money as a coach/consultant but now I’m back in product development. I have found that in some ways being an Agile coach or consultant is relatively easy compared to the jobs that most people have. Most people can actually fail at their job, but it is hard to demonstrably fail as a coach. Most people have to live with the consequences of their recommendations, but coaches often make their recommendations and move on. Most people must deliver some kind of results in their job, but coaches mostly deliver knowledge.

Recently, I went back into product development as a CTO, so I have to deliver on my own behalf and also on behalf of my organization and my company. It’s hard and scary and exciting and fun. I missed the pressure to deliver when I was a coach, but now I have a different problem. Now I have to try to do Scrum well while the real world conspires against me! I know that doing Scrum well is the way to get the best from development, but it is pretty difficult to make it look like the book. Er…books. Um…any of the books. So I think now I am experiencing Industrial Scrum.

I came to my current company to make development more responsive to the business. Sound familiar? What I found is that all the things I coached people not to do keep wanting to happen. It’s basically impossible to Disneyland Scrum out here, even for a CST ex-coach. Here is how things have turned out so far doing Industrial Scrum:

a) Engineering is now definitely more responsive. We are doing recognizable, scrum and showing potentially shippable software each sprint. (Editor’s Note: Good)

b) There is a client team and a server team instead of an integrated team. We tried having one team doing both client and server stuff, but it did not work well at all. (Editor’s Note: This will get me dumped upon if I say this in some of the Scrum discussion groups online.)

c) The Scrum Masters are also managers. I had no choice in that. You can’t just add people and there aren’t extra people hanging around. (Editor’s Note: At least it is not an official party foul to have managers be scrum masters even though it is second best.)

d) The teams are distributed across the US and China. Guess what? Daily scrum is a real pain because of time zone and language issues. Huge credit to the teams…they have dealt with the time zone problem. Language is harder to deal with, and they now run their daily scrums in Campfire as a text chat. It works much better than audio. (Editor’s Note: Coaches tend to insist that you are supposed to do audio or video in the daily scrum.)

e) We have one Product Owner for two Product Backlogs for two teams. He does not attend either of the two daily scrums. He is untrained and he is also VP of Marketing. Yet he does reasonably well at being PO. (Ed. Note: Not very good, but it’s what we could do.)

f) The training we have done has been spotty. We haven’t taken a day to do Agile team training. (Ed. Note: You mean to tell me that you have a CST/CSC as the CTO and people are not well-trained??????)

g) Everybody does not love Scrum, but they are getting stuff done and it is improving over time. The most bitching is about the number and length of meetings, and about my harping about automated test. (Editor’s Note: Sigh)

h) Much of the company attends the sprint demo every two weeks. (Good)

i) The execs are in Stage I of Agile Transformation: they still talk about projects and dates, but they also have started to use Agile words (usually incorrectly) in their conversations. (Ed. Note: The execs are usually the toughest to change anyway.)

j) After four months of Scrum, the teams are starting to break stories into tasks. (Ed. Note: Good, but what took so long?)

So, I guess I’m OK. Scrum is robust. Industrial Scrum is ugly but it delivers, and it is not ScrumBut. My goal when I came here was to build a successful Agile organization, and I think I’m on my way. There is a lot of training and transforming and adapting to do, still, but yup, we are on our way.

About these ads

One Response to “Disneyland Scrum vs. Industrial Scrum”

  1. gorange Says:

    I’d be interested in hearing more about how you dealt with the language issues.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: