I've been a big proponent of Agile Development for quite a while now, mainly since I read all about eXtreme Programming in 2000-2001.  I always liked the idea of pushing those tenets in software development, but there were always some sticking points.  Mind you, they're not exactly the same list Abhijit Nadgouda mentions in his recent post on Extreme Programming Getting Stagnant, but they're similar.

In particular, it's always been hard to convince developers to try Pair Programming.  It might actually be easier to convince managers than it is to convince developers.  They really like autonomy, creativity, and freedom.  The thought of sharing a keyboard all day just rubs them the wrong way, even though they're extremely collaborative for brief periods of time when working through a tough problem.  Maybe it's just the expectation that they should pair that causes the problem and not the actual pairing itself.

In any case, at OpenLogic we use an Agile method based on SCRUM, which, as our product manager points out, is quite nice.  Contrary to Abhijit, I think it's easier to estimate when you're doing it in small chunks, like as in a 2 week iteration.  It does take some practice, but we've gotten quite good at estimating and hitting those estimates, thanks to the feedback cycles built into SCRUM.

As with any Agile development method, SCRUM is meant to tailored to your organization.  The key is to try it "out of the box" then make changes that fit your company, team, and environment.  Expect to keep changing it over time as team members grow, move on to other projects, you create new products, etc. 

In other words, the software development method itself needs to be just as agile as the software you're building.