Selling Agile to Developers?

One question I got recently was "How do you convince developers to adopt Agile methodologies?"

And I scratched my head.

And I gave my inquisitor a funny look, like maybe he said "sea gulls" instead of "developers", but his face was steady, he really said "developers".

So I gave him some answer, indicating that "Yes, I understand what it's like to have to go above and beyond explaining what Agile is to really sell it to a dev." But I don't think I can relate at all. How can a developer see that he gets to control his work load because he (and the team) get to provide the estimates, and not be in love immediately? If that wasn't enough, a dev now has:

• a Scrum Master defending his estimates with empirical data from things like burn down charts
  
• increased communication and involvement with his team, meaning that he is going to grow professionally from it, and so are his team mates
  
• more contact with the person or people who have input on a feature, and
  
• less management that only impedes his process
• a well defined list of features to work on (though the individual features may still remain vague, at least the target is not moving anymore)

The dev will also find that he gets to deliver working software numerous times throughout the year. I can't imagine what kind of person you can hire that would say, "Really? That's what I get from Agile? No thank you." I would probably fire such a person because either a) that person had a perfect job before working for me, and he's a moron for leaving, or b) that person is not actually a developer, but is in fact a joy-hating monster, or c) that person has never actually worked as a developer before.

If you put a microphone in a non-Agile developer's home I bet his top complaints would be:

• Of the things I'm working on, I don't know which one has the highest priority so I don't know what to do first!
• My team mates have no clue... about anything!
• My boss just set a random deadline for next week after I told him this project would take a month!
• I thought I did what was asked for, but it turns out they wanted something completely different!
• I can't get any work done because my boss always asks me for status updates!

With Agile, all that crap is fixed. To me, the hard sell is to the business side. Suddenly the Product Owner has to be available for questions a lot more, and he has to maintain a prioritized list of features and bugs, rather than just a list and pretending that the entire list is filled with high priority features, all of which will go in the next release. The project manager has to change the way he reports on progress, and has to participate in stand up meetings. Sales has to reign in what it promises to customers because it can't inject a feature into the product at will (instead it can introduce a feature via the PO at the start of a sprint and should expect to get it at the end of a release instead of "by the time the customer signs"). Customers have to start really dealing with trade-offs, "Do I want feature Z, or do I want Bug Y fixed?". And there's more visibility across the board, no one can hide behind lies or shift blame any more.

The business side of the system has been working pretty well for a while, but at the expense of the developers. The developers should want to fix it if they have their head on straight. The rest of a company could justifiably take a stance of, "If it ain't broke, don't fix it", and that's a hard perspective to change. Your developers should want to adopt Agile if they're worth their weight in salt. If they're opposed to Agile, make sure to check yourself and that you are presenting it so that the benefits to developers are as clear as a bell. Agile it should sell itself if you've done that correctly.