For the last couple of years i have been a great proponent of XP. I have seen it work, i have seen it fail. I have seen products delivered where features had to be cut in a realistic fashion due to time constraints which the XP approach pointed out and i have seen deadlines for releases missed due to the aggressive feature creep that some managers think they can slide in because XP is agile after all and if the client/truth wants it, well its got to be there, init.

Any system can only carry the blame if it was rigorously applied and failed to deliver the expected result. So obviously me being negative about XP when i have seen it work would imply that in essence i see nothing wrong with the process itself but rather in its application in real life institutions. I mostly see it fail when companies adopt the xp paradigm (mostly coming over from the waterfall model) and confusing the agile process with doing no planning at all. Yes, change is a constant, but certain features are known from the start. Yes, requirements will change, but all requirements are not guaranteed to change, actually you have no grunter’s that anything will change.

So suddenly the planning game in XP has become the planning process. Features are specified with little requirements, thus stories are underdeveloped and tasks do not meet the descriptive level they should. This makes me uncomfortable, taking the strong point of XP (the iteretive adaptive nature of developing a product) whilst combining it with an extremely haphazard approach. From experience the most successful XP projects i have worked on had the features defined to a level of reasonable granularity before it started, design was 80% fixed already, the the time line as to which features were to be done in which order (according to dependency and weight/importance) mapped out.

Suddenly XP comes into its own under these conditions, it becomes a metric whereby we can determine accurately during the development process (which can take months or years) whether we are on target. We can measure the velocity (the amount of perfect engineering hours they can do in a week) of developers, the accuracy of their estimation (perfect engineering hours quoted versus time took). Using helpers like burn down charts we know each day and each week exactly what the status is of the current iteration and the project as a whole is. This is the beauty of XP, we can adjust what can be done, we can change requirements and the whole time the client knows and feels empowered.

Badly designed features which gets developed in the development process is part of r&d not product development. XP should not be a scape goat for project managers who do not want to do project management.