Strawberries, Chocolate and Tomatoes

Recently my wife and I decided to try an experiment with 7 of our children. Each child got to pick out their favorite ingredient for dinner. It could be anything they wanted, but it had to be a single ingredient. They were all told their favorite ingredient would be put into dinner that evening. They all wrote their ideas on a piece of paper. No one knew what the other person wrote down. The challenge for my wife and I was to use all the ingredients to make something for dinner.

So here's a list of ingredients, starting from youngest to oldest child.

• strawberries - very good choice
• maple syrup - another great choice
• chocolate chips - sounds like a yummy dessert
• coconut milk - again a great combination
• olive oil - this is no longer dessert, it’s something else
• tomatoes -fits well with the olive oil
• parmesan cheese - the finishing touch

We had bow tie pasta planned for that night so we made 2 batches. One batch with chicken alfredo, the other with the concoction of favorite ingredients. The results were amazing....amazingly gross. All of these individual ingredients were great, but together a gastronomical disaster.

At work I have noticed the same sort of thing with development tools. If we don't spend time looking at the big picture, we can sometimes end up with great point solutions that combined together make a less than desirable system. A great build tool combined with a great configuration management tool adding in a requirements management tool can be great as long as they can all talk to each other and use a common systematic data model. If not, then you end up with a Frankenstein system that is hard to manage and not too pretty to look at. Some simple planning upfront with goals and objectives for each of the ingredients, can quickly change disaster into a utopian system.

First, focus on a common data model. This does not mean a single database, just a common data model. That means that when I say the word Defect, it means the same in all of the tools, has common fields and if possible resides in one place.

Second, focus on integration of tools not through replication of data. Replicating and translation of data always leads to problems. It is far better to link data across tools with as little data manipulation as possible. If a tool already has a notion of defect that does not match your primary tool for defects, then you can have a problem. Where is the real defect?

Third, remember the “best of breed” tool that does not fit into the system well, does not belong in the system. No matter how good the chocolate was that went into our family’s dinner, it tasted horrible with tomatoes and olive oil. The same is true with point tools that cannot effectively talk with other tools.

Last, look for the low touch integration. Just like in a well designed system you do not want to have a highly coupled tool integration suite. It causes problems when tools are upgraded. Look for loose coupling and high cohesion in the tools that you integrate together.

Good luck with the tool soup you are creating, remember that not all great things thrown together are necessarily a good combination.

DWP

Change Escape Velocity for an Organization

I was recently measuring how long it took for an idea to move through our organization. I compared several ideas over the last 3 years. I Looked at why some seemed to hit some critical mass and then just take off, while others required constant care and feeding and took a long time to be adopted. Reviewing the changes with my boss, he said there seems to be some escape velocity for ideas in the organization. Of course this made me want to investigate this more. At the suggestion of my boss Bradley Mitchell, I opened up wikipedia and took a look at the definition of escape velocity. This is what I found out:

1. Escape velocity changes depending how far away from the surface you are.
2. Escape velocity decreases with altitude.
3. It is the speed at which an object will not fall back to earth.
4. An object at any speed as long as it has propulsion, can escape the earth’s gravity.
5. If propulsion is removed on an object that is below escape velocity it will fall back to earth.
6. If an object is at or above escape velocity it has enough kinetic energy to “escape.”

There is also a formula that allows us to measure the escape velocity of any object.


G = gravitational constant
M = the mass of the planet or star
r = the distance from center of gravity.

So if we apply this to organizational change we get some interesting observations that seem to be true.
G = Change Constant
M = the size of the organization
r = how close to core values that change are.

So if the organization is large (large M) it will take more velocity to get the organization to change. If the change is far from the changing fundamentally core values of the organization then the escape velocity is smaller than if it profoundly affects core values. This seems to make some sense. I also think we can play with the Change Constant and say that it is not constant but corresponds to how old the organization is. The older an organization the harder it is to change and therefore the escape change velocity is higher.

Let’s look at these principles and see how they might apply to change in an organization. So how can I use escape velocity observations for escape change velocity?

1. The further you are from a profound change to core values the easier the change.
2. Change is easier for smaller changes.
3. To make a change permanent you must achieve the escape change velocity or it will fall back to earth.
4. Adding constant pressure to a change, will eventually make it stick.
5. If a change is launched without enough velocity to escape, it will revert back to its current situation.
6. If a change has enough velocity at launch, it will not need constant pressure to succeed.

As you can see the engineering side of me wants to put an equation to describe how I can help an organization change. But it is never that easy. Human beings are unpredictable and in a large organization with hundreds of individuals it is closer to chaos. The key is to try and determine what things can help control the chaos during the change. Finding the perfect velocity of change for the organization is a combination of the amount of change and the size of the organization.

DWP