In his blog, Five Pound Bag, Martin Fowler talks about how the planning aspects of eXtreme Programming are misunderstood. He starts about how projects attempt to slip in extra features and how the simple aspect of stories helps people to understand that you can’t put 10 pounds of stones in a 5 pound bag.
This is the start of an excellent and good discussion at Serverside.com about the nature of planning in the XP-eXtreme Programming methodology. But like some others, I have always had a problem with XP and planning for three core reasons.
First, XP calls planning “a game” and definitely not in the fun and adventure sense. No XP tome comes out and bluntly states it; but implied is something between hoodwinking bargaining and Machiavellian intrigue. Strangely, I quite agree that sometimes developers have to be alert for the latter. But to carry such a defensive, almost paranoid posture throughout a development project is counterproductive. But as we shall see in the point just below that is what some XPer do inadvertently or explicitly.
Second, XP almost dismisses two key phases of software development – the Feasibility Study and Requirements Planning. Just look through a few XP books and articles and see how fully XPers define a role for the methodology in these critical project steps. It is as if XPers were saying – “well most developers are cut out of this process, so we will come on board after the planning game and try to straighten the ship out as required from this point on”. And, unfortunately, developers are frequently cut out of these steps which are performed by high priced consultants one or two of which might participate in the project.
Yet the Feasibility Study and Requirements Planning phases are the ones most in need of XPs Test First approach including rapid prototyping and or test simulations of major risks such as: will this fit in existing network and operational frameworks, will the GUI approach pass muster with users, can the databases talk to each other and deliver without extraordinary ETL cleaning, is the SOA approach going to expose major security vulnerabilities, etc, etc. In short the actual doers – some key developers need to be in on the shaping of the biggest story of an IT project – The Design and Expectations of What is to be delivered.
Third and finally, reading through XP tomes I have rarely found the words “take-away” and “trade-offs”as regards managing change in project deliverables. Nor have I found an explicitly delineated method for doing this sometimes difficult and (as an English bloke said it) potentially bloody contentious process in much of the XP literature. That Martin is directly throwing the gauntlet down – and saying take-aways and trade-offs have been or have to be an explicit part of XPs change to specs and iteration processes- for this I say BRAVO!
XPs contribution to IT project management and agile methods has been enormous. Test-first and measures-driven development, let no developer be left behind by institutionalizing two heads are better than one to get over potential major development roadblocks, and the customer always must be the active decider including accounting for and authorizing change – these are really solid principles. But XP has been flawed by two notions. One, planning is a game. Two, all change can be accomodated without having to incur take-aways and trade-offs. In the latter case, some change can – but XPers better be prepared for the ten pounds of shit with only a five pound bag at your uhhh …. disposal.
(c)JBSurveyer 2005