Introduction to Agility

Original from 6/18/2010: Gestão 2.0

I returned last weekend from a trip to Baltimore, Maryland, where I spoke at RailsConf. At this event we had great talks and some of them were directed not only at Ruby on Rails but at the programming career in general. One of those talks was by no one less than Robert Martin, of Object Mentor. I translated an article of his in my previous post.

I recommend watching the talk in full.

Since I started this blog, I’ve tried to explain the conditions and difficulties a Project Manager faces. But I was also being careful not to mention the term “Agile” too many times. We’re currently suffering an “agility” fever. Every CIO, CTO, Manager, Consultant, to seem “modern,” says they know “Scrum,” that they’re “agile.” This is on one hand good, because finally some companies might manage to adopt it the right way, but on the other hand it’s very bad, because we’re burning the name “Agile” because of bad consultancies implementing it wrong at the client. And then the perception many uninformed people have is that “Agile doesn’t work.”

Well, during RailsConf, I had the chance to talk to and interview Robert Martin, whose recording you can watch on Blip.TV:

From this interview, the part I want to present is the story of how “Agile” came about. Robert Martin, also known as “Uncle Bob,” has been a programmer for decades, certainly more than any of us. In the 90s he was one of those who noticed an insurgence of “light” or “lean” methodologies. Much of this was derived from manufacturing concepts that revolutionized the Japanese industry from the 60s onward.

Several big names began suggesting smarter ways to develop software. Examples were Kent Beck with his Extreme Programming (XP); Ken Schwaber and Jeff Sutherland with their Scrum; Alistair Cockburn with his Crystal. Seeing that most followed a similar line of short iterations with feedback and a lot of communication, Uncle Bob called Martin Fowler — another well-known name in the world of software architecture — and together they began organizing a meeting, summoning dozens of these professionals.

The legendary meeting took place at the Snowbird ski resort in Utah, between February 21 and 23, 2001. The result of this meeting was the creation of the “Agile Manifesto.” It outlines 4 values and 12 principles that all the participants agreed on as the minimum common denominator in the practice of software development. The manifesto says:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and Interactions over Processes and Tools

Working Software over Comprehensive Documentation

Customer Collaboration over Contract Negotiation

Responding to Change over Following a Plan

That is, while there is value in the items on the right, we value the items on the left more.

As I said before, currently there’s a certain growing fever in the adoption of agile methodologies. Worse than that, there’s a tendency to expropriate the term “Agile” or its derivatives like “XP” and “Scrum,” literally creating frankensteins blending the old way with the new way. Frankensteins like trying to mix RUP with Scrum, or PMI with Scrum, and so on.

These are opportunistic attempts riding this fever to make easy money. Some companies, for example, value a manager’s resume having a “Certified Scrum Master” listed and other irrelevant things of this kind.

And to be even more antagonistic, many try to implement agile methodologies following the various techniques “by the book,” that is, dogmatically, and obviously, every Dogma is, by definition, dumb.

Recalling the 4 values: the emphasis is not on implementing a methodology, the priority is working software and value to the client. The first Agile value clearly says: “we value People and Interactions much more than Processes and Tools,” but what’s currently happening is the opposite: attempts to push processes, methodologies, and tools.

Now is a good time to start demystifying the Agile world. This is just an introduction, but as Uncle Bob says in the interview: follow the originals. If you’re really committed to improving things, to delivering projects with quality and value, disconnect from this new generation of consultancies: start with the first books of Ken Schwaber, Kent Beck, Alistair Cockburn, Mike Cohn.

Ask yourself all the time: am I in agreement with the 4 values?

If by chance you’re putting more emphasis on the process than on people, you’ve already started wrong, very wrong.