On Tuesday, 18 June 2013, Jon Hatfield wrote:
This is controversial, however looking at the original manifesto I would not weight the left over the right. Good docs are essential for testing and communicating functions to esp. non technical people and likewise a plan is essential - responding to change is good within reason though if excessive you end up with headless chickens wondering what is going on. A good plan considers short term, long term AND, if a proposed change is sensible and / or necessary, is changeable. In my experience a polite "no, you idiot!" to the client regarding a proposed change that is not wise, with an explanation and alternative, is appreciated and better than simply implementing their every whim. Plus they respect you for such guidance, after all we are the experts at designing systems and they pay us to help, not be their servants.
A bit of a digression there... my point was going to be, given the consensus that agile is a nice idea but not perfect, Agile part 2, revised, in the future?
I don't see anything from the above that invalidates anything from XP, or 'Agile' in general (whatever that may mean). Looking at the assertions one-by-one:
Good docs are essential for testing and communication
I (like Wes above) have seen far too much bad documentation (both internal and external) and far too many projects that insist on delivering "documents over working code" to agree with this assertion. I *do* agree that testing and good communication are needed, I just think that in most cases documentation is not the best way to accomplish that goal.
A plan is essential
"Plans are worthless, but planning is everything" -- Public Papers of the Presidents of the United States, Dwight D. Eisenhower, 1957
In my experience a plan is not essential, and often gets in the way of a team's successful delivery as it sets in stone the teams' and the customer's ignorance at the time when rigidity is least desirable. There are very good physical realities that dictate that it is pointless (as opposed to difficult) to plan software projects; 'Agile' methods are the reaction to this experience. What I have found to matter is understanding and shared consensus, and adapting to changing circumstances, not predicting the future. I (and others I've met and talked to in the Agile community here in London) have successfully delivered projects without needing anything that would be recognised by a PRINCE2 practitioner as a project plan.
A polite "no, you idiot"...
Calling the customer an idiot is not polite, no matter what tone of voice it is said in. I have also observed that changing a client's mind is often a lot more challenging than rationally explaining why you think that they are mistaken...
There are many approaches (e.g. NVC) and tools to enable better communication, I have found it not just possible but desirable to get a point across and negotiate a win-win without denigrating the other's point of view; communication is not a zero-sum game.
@Jon: I'm guessing that your opinions are founded on a basis of "I haven't seen anything that contradicts my experience so far" - this is a classic 'black swan' argument. Trust me when I say that the black swans are out there, and there are plenty of people like myself who would be happy to show you them.