Friday, October 7, 2011

Scrum is a major management discovery

Steve Denning wrote an article titled "Scrum is a major management discovery."

For those of us who have been doing Scrum for a while, saying that Scrum "is a major management discovery" is, well, obvious.  Or it is clear and unfulfilled.  Or it is something we have forgotten.  Or it is something we never thought about ("I thought Scrum was only for people like me, developers!").

In any case, I think it is important to say.  Both today and in the future.

Steve Denning is a good and smart man. A man on a mission, and I think a good mission.  Here is his article.

Why is Management important?

So, let's look at this hypothesis (a major management discovery) from a certain point of view.  What is important? Or where is the power?

If one believes that managers are responsible for the mess we are in or, in any case, only managers have the power to change things, then the fact that Scrum is a major management discovery is quite essential.

A contrary hypothesis is that, despite what some people may think, the real power is with each individual, and resides there in such degree as that person is persuasive and connected to the truth (some combination of those two).  In other words, any one of us can have great affect on our brethren if one speaks well and if one proposes actions that are connected to the truth.

Aside: What I have suggested is that the power 'vested' in managers is actually largely a facade of power with little substance, except that other people happen to believe it sometimes. Real power only comes from a person's leadership skills, eg, their ability to persuade and to speak the truth.  And anyone, with or without a manager's official title, might have and use these skills.  How many Arab springs, or 1989s, or American Revolutions will it take until people see that "we hold these truths to be self-evident, that all men..."??  [Be he right or wrong (in whatever dimension you wish to speak of) Hosni Mubarak thought he was pretty darn powerful only a few months ago.]  And that means we all are equal, ultimately, in power.  Even power. Yes, yes, I know it seems to many of you very impractical of me to say so.

Now this second hypothesis does not imply that we leave official 'managers' out.  It just means that anyone can pick up the torch.  Anyone can start the change, or take it to a new level.  You don't have to wait for the managers to be convinced!

Scrum changes everything

I agree with the view that as soon as one introduces Scrum into an organization, the people start to see the impediments and they start to realize that almost everything must be changed.  At least some, not completely, but at least some. (Yes, completely, in some areas.)

I agree, based on experience, with the view that Scrum can have a greater positive impact (on people, on the firm, on more customers) if the managers and 'everyone' in the organization 'get it'.  

But Scrum can still make a serious impact on some people's lives before 'managers' know about it.  Or agree with it.  Or do much about it.  We can definitely start Scrum before managers fully 'get it'.

It is perhaps now worth repeating that Scrum itself is not a silver bullet.  Scrum does many things (and one might say that the spirit of Scrum does yet many more things), but one of the chief of them is to set up an inspect and adapt system. This system shows where the biggest problems are.  But it is up to the people to take action on that new knowledge.  Scrum will not magically, by itself, fix things.  The people must do that. And often that means that the managers must (or should) approve the fixes (agree, give people's time, get money approved, whatever).

Also, the basic ideas of Scrum apply to many kinds of work, and in general apply at all levels of an organization.


Some additional key ideas

In his article, Steve mentions 10 salient ideas about Scrum.  I strongly recommend that you read his article and consider them.  Steve himself does not think his list is perfect or exhaustive, but it is useful to review and consider and put into action more.

To him, some of the ideas I will mention below were said or implied in what he already said. But I want to make them more explicit.  And perhaps I add one or two new things.

My idea is that these underlying principles of Scrum also apply to management work and to the work that managers do with teams.  So, managers, listen up:

1. How do we know if thinking (knowledge work) is good?  Scrum's idea is that we let 'em think for a while, but show me some 'working product' at the end of the Sprint!  (say, every 2 weeks) So the right people can decide if it is useful thinking.

2. "Six blind men and an elephant."  No one understands 'everything' anymore. To figure out anything, we need to get a small team together, have them fight about it and create knowledge together, and then we can make some progress that the customers would really care about.

3. "The bad news does not get better with age." Yes, some of the suggestions of Scrum and Agile are 'extra' overhead from a certain point of view.  But the benefits of that extra overhead are so great in discovering 'bad thinking' (simple example: bugs in the code) that it is obvious we must accept the 'overheads'.

4. We always start with seriously incomplete knowledge. Therefore we must enhance learning. We must accept small failures as the best way to learn fast. (Well, we must accept small failures in any case. But use them to learn fast also.)  And we must organize things in such a way as to take advantage of that learning as fast and as much as possible.

5. "People are remarkably good at doing what they want to do."  By and large, knowledge work is (or should be) very creative.  (Again, a lot of the creativity happens as a team of 6 or so.)  And the work, if you remove the de-motivators, is inherently interesting (well, to those who will do it well).  So, we must treat the workers more as humans with intrinsic motivation and much much less as things or cattle that must be prodded.  Daniel Pink's book "Drive" gets into how motivation works with people.  But the basic principles were noted by some wise coaches some thousands of years ago when they said: "Do unto others as you would have them do unto you."  Of course, we were all taught this by our mothers, but who knew this would actually help us and our firms make more money in business?  Who knew that customer delight is driven by workers having more fun!

Aside: My strong bias is with Peter Drucker (wikipedia him), when he said that the purpose of the firm is to satisfy customers. (And that shareholder returns were just a constraint.)

6. "You have to go slow to go fast."  Lean-agile-scrum have shown that there are many counter-intuitive principles that must be followed if a team is to achieve real success.  Well, the principles are counter-intuitive to us, who have been trained so long in the wrong ways of thinking about these things.  So, multitasking, stretch goals, giving teams multiple projects at the same time, being sure everyone is 100% occupied, large queues of work -- all these are almost always stupid ideas, even though they seem good from a certain point of view.  Who knew the customer was important?  Who knew that if you did not allow slack in the system, you just about assured that the customer would never see ANY feature any time soon?  One of our favorite counter-intuitive sayings is "you have to go slow to go fast".  Meaning, as indicated earlier: Yes, early and frequent testing is an 'extra' overhead, but the benefits in keeping the bad news from getting worse with age are so great that, it is obvious, we MUST go slow to go fast.

In closing

Steve mentions dynamic linking. From that phrase (which I am interpreting a different way than Steve did) I want to lastly emphasize that the values, principles, and practices of Scrum are themselves dynamically linked.

Scrum, if played well, is like a good ice hockey team.  Every player on a great team is inter-linked, and every pass or shot is inter-linked. So that a single pass can be both a great defensive move as well as set up an offensive break-away that leads to success (puck in net) seconds later.  So, similarly, all these things about Scrum are inter-linked.  Fluidly. And some of the linkage is a dynamic tension. Simple example: In general in agile we want less documentation but we want more and better communication.  Which might mean more documentation of just the right sort (I'll call this an agile specification), although overall there is less documentation.

We have so many more benefits to get out of Scrum.  For so many more people.

No comments: