Introduction to Agility
Original from 6/18/2010: Gestão 2.0
I got back last weekend from a trip to Baltimore, Maryland, where I spoke at RailsConf. It was an event full of great talks, some aimed not just at Ruby on Rails but at the programming career in general. One of them 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’ve been careful not to repeat the term “Agile” at every turn. We’re in the middle of an “agility” fever. Every CIO, CTO, manager, or consultant, to seem modern, says they know “Scrum” and that they’re “agile”.
That has a good side: some companies might finally adopt these ideas the right way. It also has a bad side, and a big one. We’re burning the name “Agile” because of bad consultancies that implement everything wrong at the client. The result is the perception, among the uninformed, that “Agile doesn’t work”.
Well, during RailsConf, I had the chance to talk to and interview Robert Martin, whose recording you can watch below:
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 the rise of “light” or “lean” methodologies. Much of that came from the manufacturing concepts that revolutionized Japanese industry from the 60s onward.
Several big names started proposing smarter ways to develop software. Kent Beck with Extreme Programming (XP); Ken Schwaber and Jeff Sutherland with Scrum; Alistair Cockburn with Crystal.
They all followed a similar line: short iterations, constant feedback, and a lot of communication. Seeing that pattern, Uncle Bob reached out to Martin Fowler, another strong name in the world of software architecture, and together they began organizing a meeting, summoning a group of these professionals.
The legendary meeting took place at the Snowbird ski resort in Utah, between February 11 and 13, 2001. Seventeen professionals spent three days there and walked out with the “Agile Manifesto”. It brings together 4 values and 12 principles that all the participants accepted 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, there’s a growing fever in the adoption of agile methodologies. Worse than that, there’s a tendency to expropriate the term “Agile” and its derivatives, like “XP” and “Scrum”, creating real frankensteins that blend the old way with the new. It’s the case of trying to join RUP with Scrum, or PMI with Scrum, and so on.
These are opportunistic attempts riding the fever to make easy money. Some companies, for example, insist on a “Certified Scrum Master” in a manager’s resume, among other equally irrelevant things.
And, to make it worse, many try to implement agile methodologies “by the book”, that is, dogmatically. Every dogma, by definition, is dumb.
Back to the 4 values: the priority is working software and value to the client. Implementing a methodology comes after that, if it comes at all. The first value is clear: it values Individuals and Interactions much more than Processes and Tools. What we see today is the opposite, an effort to push processes, methodologies, and tools.
Now is a good time to start demystifying the Agile world. This here is just an introduction, but the advice Uncle Bob gives in the interview holds: follow the originals. If you’re really committed to improving things and delivering projects with quality and value, drop this new generation of consultancies. Start with the first books by Ken Schwaber, Kent Beck, Alistair Cockburn, and Mike Cohn.
Ask yourself all the time: am I in agreement with the 4 values?
If you’re putting more emphasis on the process than on people, you’ve already started wrong. Very wrong.