(R)Evolutionary Agility: Why Agile?

At the end of May I participated to a seminar organized by the Industrial Association of Salerno on Lean Management and Continuous Improvement (btw a surprisingly crowded event with more than 500 participants from more than 200 companies).

One of the most interesting takeaways for me was from Minoru Tanaka, expert of Industrial Engineering and CEO of JMAC Europe. In his speech on Toyota Production System he stressed the vital importance of understanding “Why” you are doing a Lean transformation and even every single improvement or change, to get a real commitment to succeed.

That’s why I decided to include during my agile trainings a short module called “Why Agile?”

The purpose of this very interactive module is to engage the class in a discussion to share and agree about why they are attending the training, what is the purpose of the Agile journey they want to (or are told to) start and, finally, what are the intended issues they think an Agile SW development can address.

I ran this module 3 times already and I can tell you that the variety of answers is sometimes impressive, showing 2 things at least in my view: how many myths Agile development is surrounded from and how many, sometimes false, expectations come from discussions about agility.

I do not want to list all the answers here and many are right indeed. It’s just that sometimes, even right answers are not pointing to the ultimate goal of agility, but rather to (what I call) sub-products coming from all goods inherent for instance to Focus, Collaboration or Cross-functionality.

The core of the question comes actually from the nature itself of SW development, especially in the 21^st century: SW development is a dynamic complex system, where change is king.

Nothing endures but change!

That’s what Heraclitus of Ephesus said in the 6^th century B.C.

But we all know that changes are going faster and faster in the world around us: current change rate is unprecedented, even change has changed.

There’s only one thing you can be sure of when you start a project: almost everything will change! Requirements will change, environment will change, solution will change, because you will most probably discover things you were not even aware of 2 weeks before.

So you have a choice: you can pretend change does not exist and that your plan will stick or accept the reality and find a way to live with change.

It’s like the law of gravity: you can take it into account or not, but you’d better do it, if you decide to jump off a 30-floor skyscraper ;o)

To describe the core of Agile, I like very much the great summary I heard from Craig Larman at a Conference in Shanghai last June: Agile is mainly intended for a 2-fold purpose: