The Agile Analogies

-versione italiana online a breve-

Put it simple, being agile means being able to deal with change faster and more effectively. Agile was born for software development, but it undergoes all aspects of an enterprise model. Agile is an enterprise state of mind, or a desired condition.

A well known –and quite abused- agile analogy is the two architects one.

Once upon a time, a long long time ago, an architect was asked to build a pyramid for the living pharaoh. The pyramid had to be large, and finished before the pharaoh’s death. The architect had to deal with two major uncertainties: he did not know how large the pyramid had to be, and he did not know when the pharaoh had to die. He struggled then with engineers, ministers and fortune tellers for a while, and at last he started building the pyramid. He was bulding it the standard way, one floor after the other, when suddenly the pharaoh died and had to be buried in an unfinished flat-roof pyramid. Of course the architect lost his head.

A few years later another architect was asked to build a pyramid for the new pharaoh. Of course, he was having exactly the same problems as his predecessor. But he was a smart and agile guy, and started building a small pyramid, and made it grow adding sides over time… When the pharaoh died, he had a large enough, pointy pyramid, and the architect stayed alive.

This is of course fantasy… But I wonder… Maybe Menkaure died a bit too young?

In fact, I don’t like this analogy that much. Pyramids need foundations, and you have to know how large will your building be before laying the foundation. Moreover pyramids are stuffed with secret chambers and tunnels, and they would look funny indeed if built the way the second architect did.

I think there is a much better analogy.

Tangram is a dissection puzzle, but I would not call it a child’s play. It features seven shapes, and you must form a figure given by an outline using the pieces. Pretty hard. There are thousands of possibilities….

Tangram shows in an easy and explicit way how an enterprise should act, rearranging its parts in response to changing environment. Each shape could represent a service, an application, a team or a single person. And all of them have to be ready to rearrange themselves upon necessity. And, far more important, each shape must be conceived and shaped with the capability to rearrange and adapt to any other shape in the set. Your enterprise will not be agile, unless you rethink holistically at all boundaries between the processes of your business. Moreover –and unavoidable-, You’ll have to know all the people in your enterprise to have the chance to move the right person to the right place to meet the given outline.