A re-write....

I have taken an article out of context, and re-written it below. Here is the original:
http://www.only-positive-news.com/archives/1232

See how you like the re-write:

If social psychologists have proven anything during the last 30 years, they have proven that the actions we take leave a residue inside us. Every time we act, we amplify the underlying idea or tendency behind it. Most people presume the reverse: that our traits and attitudes affect our behavior. While this is true to a certain extent (though less so than commonly supposed), it is also true that our traits and attitudes follow our behavior. We are as likely to act ourselves into a new way of thinking as to think ourselves into a new way of acting.
There is a practical moral here for us all. Do we wish to change ourselves in some important way? Perhaps get better at Scrum or convince people of the principles behind Scrum? Well, a potent strategy is to get up and start doing that very thing. Start doing Scrum. And ask them, as Coleridge said, to willingly suspend disbelief. Don’t worry that you don’t feel like it. Fake it. Pretend that you want to do it. Feign optimism. Just do it. Do it as an experiment.
In doing Scrum, they typically find that all the fears of how it won't work melt away, or at least become much less. And they also experience all the good things about Scrum (one example: the building of trust between the technology side and the business side).
Yes, telling people to act or talk positively sounds like telling people to be phony. But, as usually happens when we step into some new role–perhaps our first days “playing” parent, salesperson, or teacher–an amazing thing happens: The phoniness gradually subsides. We notice that our uncomfortable sense of being a parent, for instance, no longer feels forced. The new role–and the new behaviors and accompanying attitudes–have begun to fit us as comfortably as an old pair of blue jeans.
The moral: Going through the motions can trigger the emotions. Surely you’ve noticed. You’re in a testy mood, but when the phone rings you feign cheer while talking to a friend. Strangely, after hanging up, you no longer feel so grumpy. Such is the value of social occasions–they impel us to behave as if we were happy, which in fact helps free us from our unhappiness.
Granted, we can’t expect ourselves to become adept at Scrum overnight. But rather than limply resign ourselves to our current practices (waterfall?), we can stretch ourselves, step by step. Rather than waiting until we are utterly and completely confident that we *know* Scrum will work in our new special situation, we can begin. If we are too anxious, modest, or indifferent, we can pretend, trusting that before long the pretense will diminish as our actions ignite a spark inside–the spark that will lead to happiness.
* * *

Changing people (that would include you)

I am involved with Scrum as a coach and trainer. And occasionally (well, more or less daily), I get the question: "I would really really like to do Scrum (better), but I need to change X, Y, and Z." And X, Y and Z are people or groups of people at that person's organization.

And, just to remind us of how utterly impossible it feels, let me add. "People don't resist changing; they resist being changed." ("Zen master, why such an impossible koan today?")

(We must also remember that it is not only "they" who must change. We must change also, starting with our blindness to our own need to change. Arrogance is not charming.)

And I totally sympathize. I too would like to see Scrum used more and better (or better and more). And to me the key impediment is in the mind of man (or particular people).

Or is it in the mind?

I take Hapkido, and I truly like and greatly greatly respect the master of the dojo. An American. One of his favorite phrases is: "Fake it until you make it." And of course that has many applications.

Then, look at this article: http://www.only-positive-news.com/archives/1232
Or maybe better, look at this re-write of that article: http://agileconsortium.blogspot.com/2010/03/re-write.html

I am not all into some of the touchy-feelly stuff in the original article, but the basic point rings truer and truer to me. The action teaches the mind what the values and principles really are. Well, it would if they were paying more attention. And, even when not, it does teach them some. Reality is a great teacher. And then the wiser teacher can teach based upon experience, not upon mere ideas in the mind.

So, today I heard this saying: "We do not think our way into a new way of acting, we act our way into a new way of thinking." (A version of this saying is used in the article.)

Surely this saying needs some explanation, especially for those who are strongly (and only) rationalists. And surely it is not complete. But I can tell you from my experience that a man who is only convinced in the head will do the practices of Scrum in a very weak manner, while a person who "gets it" will do them so much better. ["Gets it" is the simple, opaque and yet totally obvious phrase some of us coaches use. If you have not experienced it, apologies, because it will sound totally stupid.]

I call Scrum a "drama-in-real-life". By which I mean that in enacting the drama, the people will learn. All the parties. And, with a wise teacher, over time many good things will result. Many good things will be learned in enacting the drama.

So, one answer to "how do I change those people?" is: start the drama-in-real-life of Scrum, and use that to enable them to change. Wait for the teachable moment, and show them what they are almosting in their knowledge of agile. You can observe a lot just by looking, Yogi said. And learn a lot just by acting, Kert said.

Additional Value from the Scrum course

In the prior post, I spoke of a simple way of measuring the value of a scrum course. And the real subtext was: You must measure velocity (productivity) and you must increase velocity dramatically. (And, oh, by the way, a course might help you do that.)

But aside from velocity, does the CSM course provide other values?

I think yes.

So, what might they be? I would be very interested to hear how you would put this (or these).

X has already mentioned that it bring a common terminology. This is very helpful. In many ways, and to many different people.

I have heard a senior manager say: "If they only thing I get is greater visibility into where we are, that's plenty. I don't have to have anything else get better." And while the Scrum course won't guarantee that, one of the main benefits of Scrum is that, if you do it right, everyone gets greater visibility. [Now, we are concerned that some managers will meddle more, in a hurtful way, if they get greater visibility, but almost always the meddling goes down some, at least.]

People work less in isolation. I think this is a big improvement. It is a more humane way of working, in this way. Less lonely.

Teams are held accountable for something important, rather than an individual being held accountable for something fairly unimportant and outside his/her control. This is, in general, a big improvement. There are issues, and there are ways that Scrum still holds (appropriately, I think) individuals accountable, so this needs further discussion, but in general, a clear improvement.

More fun. Scrum says that the team must be having fun (well, mostly fun) or its not being done right. And, if it is done with "right" limits, it is always more fun (or so I have found). To me, this is a value on its own.

More focus on impediments. The PMI folks might argue that we always were working impediments, and of course in some sense this is true. But Scrum brings a lot more rigor and effective action and focus on the top impediment, one at a time. Everyone can contribute, the team can identify and prioritize them and devise a plan to remove each one. Even if we don't measure velocity, this is a big value add in many ways (eg, more satisfying and less painful way to work).

So, that's a start. Hardly a complete list of the value. But a start.
You could say that these start to explain how Scrum "magically" leads to greater velocity and a higher delivery of Business Value.

Value from the Scrum course

I wanted to reiterate views I have expressed elsewhere, I think.

My best guess is that a typical development team of 7 or 8, including the product owner and the scrummaster, costs about $1 million per year. Including all related costs. (In my opinion, every team should know their total annual cost.)

My best guess is that a typical development team can produce about $3 million per year in Net Present Value. Based on what they develop; ie, their share of the "earnings" from the product. This is discounted over the 3-5 year typical time horizon. (In my opinion, every team should be given an estimate, and some data after the fact, of the value of the work they will be doing, say, over a year. This concentrates their minds wonderfully.)

From a Business Value viewpoint, the goal of the Scrum course is to significantly increase the productivity of each team. So, let's assume the whole team comes to the Scrum course. And some related managers. Let's assume the team can double their productivity (their velocity) within one year. Let's assume in years 2 and 3, they continue to improve. So, saying we go from a NPV of $3 million per year to $6 million per year is not a stretch.

Let's say that there are other costs/factors that also contribute to the doubling (coaches, impediments removals, etc). So that the Scrum course, which teaches 3 teams, only gets 25% of the added value. 25% of $9 million is: $2.25 million. (Does the scrum course deserve more or less than 25%? You judge.)

Now, get out your spreadsheet and calculate the value for yourself, with your own assumptions. See XLS file here. Let me add that there are many other benefits, but let's ignore those for now.

By the way, a decent team (not a great team) in Jeff Sutherland's opinion should be able to double velocity in 6 months. Many do in 6 weeks. And some companies are seeing an improvement of 5x-8x for every team and it happens quickly.

A couple more things to say:

1. The purpose of the course is not to convey explicit knowledge, although that happens. The key purpose is to get the people willing, wanting, and waiting to change. "It's the Tacit Knowledge, stupid." (To play with a political quote from the past century.) Without this change, which always happens somewhere else than the brain, no worthy improvement will take place.
2. The team must be having fun. I won't explain that more here.
3. The team must be working reasonable hours (40 or less in total).
4. Thus, the way to velocity improvement is by impediment removal.
5. And thus, managers must be removing some impediments (and letting the team self-organize) or the full amount of improvement won't happen.
6. Finally, this is still not a silver bullet. Teams can be dysfunctional and projects can still be impossible. (The good news is that these serious problems can be identified very much sooner.)

Now, our challenge to you. Have you achieved a measurable and believable increase in your own baseline velocity? How much?

You owe it to yourself, your teammates, your company, your customers, and right now to the world economy, to get your team going. You can do it. If you feel you can't change your organization, first, don't believe yourself. "The culture" can resist one or two people. It cannot resist a fired up group that is right.

Still, if you can't change your organization, then you must change your organization. And then double there. You will be proud of yourself when you do it. You know you can. We know you can; we cheer you on.

Doubling is not enough, but like 12 lawyers at the bottom of the ocean, it's a good start.

Business Value Communication

In March I did a short workshop on Business Value Engineering at ScrumGathering in Orlando. Very interesting to me, although it was mainly about the work that the attendees did.

As I commented to them, it certainly was not about what I said. It was not even about what they learned in the session. It is about what they will do. Later.

What did I learn? Well, there is always so much more to learn about this subject.

One thing that became obvious to me is the importance of BV communication.

One of the main reasons to do Business Value Engineering is so that "everyone" can talk about it. So, it needs to be a set of words and ideas that everyone finds interesting, fairly simple, and compelling. Everyone starts to talk the same language. I find this currently very rarely.

Just to talk about it enough so that the basics feel, well, basic and well-understood.

I guess it is useful now to talk about the larger purposes of communication, at least in this context.

So, let's put this in the context of Scrum and talk about the following people:
* Product Owner
* ScrumMaster
* Implementers
* Stakeholders (to the PO, in this case; typically people in the business side of the company)
* Managers (too broad, but we'll leave it at that for now)
* Customers

And of course we can have other groups of people also.

Now, let's restrict this further for now, and say we want a common understanding for this effort (say, next 2-3 releases for a given product) of what Business Value means (and, implicitly, how we will measure it).

So, what are the benefits of communication in this restricted context?

Well, my quick answer includes the following:

• getting everyone on one page
• getting several hands on the elephant, to help discover more fully the true nature of BV for this effort
  
• affecting concrete team actions; eg, what each implementor does
• reduce conflicts amongst stakeholders (since they can see clearly where the greatest BV is and isn't)
  
• minimize the PO as a single point of failure
• by becoming clearer in expression, we become better able to identify flaws in concepts and theories
• as suggested earlier, once we clearly and more concretely conceive of business value, we can then work harder on measuring it (which is typically hard)
• motivating the team

Do any of these need further explanation?
Aren't all of these fairly obviously compelling?

To clarify the bullet point about metrics, let me use words that my 6Sigma friends like to use. They say it is fine to have a general definition of a metrics, but then one must have also an 'operational' definition that allows one to actually measure. Some people need the wordy definition, some people do better seeing exactly how you will measure it.

These are some benefits; no doubt others to add and better ways to express them.

Your thoughts?

Business Value Engineering Workshop

At the ScrumGathering, Tues (tomorrow) I will do a mini workshop on Business Value Engineering. At 1:30pm.

Here are the slides: http://bit.ly/cXmYaI

Most of the slide deck is for reference; only a few of the slides will be used in the workshop. The mini workshop is about 2 exercises.
#1 Define at your table Business Value.
#2 Articulate your BV Engineering approach. (Map, BV Model, Theories, Timeboxes/Feedback loops)

I hope in this way that people will start to see this framework can be used. And also used to look at all the other great ideas about business value that others are discussing. Each of those must be put in the context of an overall framework. This BV framework hopes to be that general context.

BV Engineering is a framework, kind of like Scrum and kind of like Lean. So, as in Lean, we ask that people make explicit the BV "cycle" and approach, much as Value Stream mapping does.

I hope you will find these ideas and practices useful.