Food for Thought: Agile development

Food for Thought: Agile development

I was reading an interesting article ( and one part caught much of my attention. Worth sharing.

The key principles of the Agile Manifesto include “value individuals and interactions over processes and tools” and “value responding to change over following a plan.” So what did companies create and fervently follow? Agile processes, tools, and plans.

Tiago -

It's so true. I was reading an article a while back (wish I could find it) by one of the key folks involed in the Agile Manifesto... the group was REALLY disappointed with what happened when they wrote it. It quickly got a lot of attention, and within a few months people were writing books on "how to do Agile" and calling themselves "Agile consultants" who would "teach Agile", and they knew that Agile's spirit was really not understood by people.

Agile isn't a product or a process that can be bottled or taught, or it is a way of thinking and an approach to the world of development. It's the same way I can't teach someone to use good variable names. Either they understand how to do it or they don't, but I can't change the way someone thinks.

I have a client whose project is failing so far because they aren't following any process to stabilize code.  Interestingly enough, my client claims to have had experience training Agile to people.
So far I've seen more success when processes were in place than when there weren't, but I've also seen processes strangle projects to death.  I've found so far that the key to success is a team-wide acceptance of the proper mindset coupled with a disciplined process involving strong communication and short iterations.

Justin's comparison of Agile with writing good variable names is a good one.  It's time for a new manifesto, and I think it should be based on the Little Book.  Anybody want to help me draft one?
@Justin: Maybe it was this one Agile Is Dead (Long Live Agility)
Tiago -

That's the one!

Here's the thing:

Processes are how organizations protect themselves from people who do not know what they are doing. That isn't a bad thing... no one can know *everything*.

But when you have a process for everything, or feel the need to have a process for everything, it's a big red flag that you have the wrong people, or you really need to simplify what you are doing.

There are exceptions of course. It's good to have checklists for mission-critical tasks like restoring servers from backups or deploying code... especially if these are things that do not happen very often.

But when I see an environment that needs to takes away the freedom to make decisions for everyday tasks, that tells me that the organization does not trust their people to make decisions on their own, which is a big, big problem.

I totally agree!
Thanks for leading me to that article - it's in the lines of what I was thinking too.

Justin, when recruiting I always have my mind set to capture people's values, more then technical skills. It's not that they are not important, but you can teach technical skills, but you won't change their values...
Someone (can't remember who) once said to me

"You can give good tools (practices, methodologies etc.) to bad people and they will fail.
You can give bad tools (... etc.) to good people and they will make it work.
You can give good tools (... etc.) to good people and they will make it work even better".

I believe I also read in one of Alistair Cockburn's books that his conclusion from studying successful projects was that the single factor that lead to success was the people on the project.

Most good people I have met don't really need the process and discipline because I find that they have it inbuilt in themselves.

We could all switch to DAD ( but that's probably just IBM's way to make their methodology seem agile :-)
I like

Although I'd appreciate any resources that start smaller and simpler..?

Converting teams and organisations from Waterfall to Agile is a mission!
Andy Hunt, one of the original authors of the Agile Manifesto has been promoting an agile re-birth via what they call the GROWS™ Method. They even trademarked the word to prevent abuse. :)

The site doesn't have much content yet but this presentation sheds some light into what they are thinking:

Anti-fragile and feedback. Trying to make up for the failures of "agile." - Andy Hunt

Awesome! thank you Davide.
Also, there's this awesome post from Handy Hunt - The Failure of Agile