The Fun Theory

Thanks to Mario López de Ávila Muñoz for posting about this in the cmsig group at Yahoo:



Here is a link to the original page.

There is a good point here: People will change their behavior if it is fun to do so. It is something to remember.

Traits of Agile Organizations

I wrote the following list of traits of agile organizations in a discussion at LinkedIn. I decide to preserve it here until I figure out what to do with it. 

Is there anything you think should be added or removed from the list? Are there any organizations beyond those mentioned in the list that you beleve are also agile? Comments are very welcome.

• Likely to focus on core values instead of core business 
• Likely to be network structures 
• Likely to limit node size to 100-200 people (Virgin is an exception nowadays) 
• Likely to have nodes responsible for complete revenue flows 
• Likely to have decentralized command structures (in order to reduce response times and be more opportunistic) 
• Likely to emphasize self-organization 
• Somewhat likely to be democratic (W.L. Gore and Semco) 
• Unlikely to emphasize economics of scale (though they use it when appropriate) 
• Unlikely to standardise procedures across nodes. (Quite obvious why. Virgin Galactic, Virgin Trains and Virgin Balloon flights can hardly standardize their procedures. Semco does not standardize too much across manufacturing units because it would reduce resilience, even if it could bring them short term economic advantages.)

Sent from my iPhone

About Context

I have been involved in a discussion about the importance of context when solving wicked problems in a LinkedIn group. (The thread didn't start out that way.)

Here is a little story for everyone who believes problems can be solved without understanding their context:

A small car company had great success with a car model, so great that they decided to build a factory in a country new to them and open up a new market. Because this particular model was such a great success, they decided it was the best car they could hope to build, and that their way was the best way to build it. Therefore, they decided that their new factory should be an exact replica of their existing factory, and that it should build cars exactly the same way.

Unfortunately, cars made in the new factory did not sell very well. Sales were abysmal. Worse, cars from the new factory were involved in several accidents. Cars from their old factory had excellent safety records.

Management decided to ship half a dozen cars from the new factory to the old one to let a team of engineers figure out what was wrong. The team examined the cars, but found nothing wrong. The cars from the new factory where identical with the cars from the old factory, and just as good.

The chief engineer decided he needed to go to the new factory and see for himself how the cars were put together. There had to be something wrong with the way it was done at the new factory.

When the chief engineer arrived at the airport he was picked up by a driver using a car from the new factory.

When the chief engineer arrived at the new factory he was greeted by the plant manager who looked very worried and told him: "I am very glad you are here. We have tried everything we can think of to make our cars just like yours. We are at our wits end. If you can't solve this, we have to close our entire operation down."

"Don't worry", the chief engineer said, "I figured it out on the way from the airport. Here is what you need to do to solve your problem..." Then he told the plant manager.

What did the chief engineer tell the plant manager?

To see the answer, select the white text here: The chief engineer told the plant manager to move the steering wheel and all pedals from the left side of the car to the right. The old plant was in a country with right hand traffic. The new factory was in a country left hand traffic.

The point of the silly little story is of course that best practices are always dependent of context. and yet, we forget again and again to define the context when we try to discuss best practices, or solve complex problems.