The History of Planning in eXtreme Programming

Discussions

Blogs: The History of Planning in eXtreme Programming

  1. The History of Planning in eXtreme Programming (4 messages)

    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.
  2. http://www.joelonsoftware.com/articles/SetYourPriorities.html
  3. Personally I do agree with what he says. Unfortunately, most people and processes are still "old school", and unless they get the concept of:

    * no fixed end date for ALL requested features
    * two people working on one thing together on the computer
    * the decision making person actually working with the team
    * you will get very little "paper" documentation with your product

    they are not going to be paying you.

    I would have to agree with what someone told me about methodologies. If you have good developers, any methodology would work anyway.

    I also find that XP does not scale down to accomodate the occasional bad seed that got his/her job by nepotism. Some of the more heavy process oriented ones have somewhat of a redundancy through excess documentation.

    I think best methodology from what I have read is a combination of RUP process with XP practice. But I haven't seen that done in any of my projects yet.
  4. XP Planning explained[ Go to top ]

    Resources , Scope , Quality and time are the major factor or XP and they can be explained in some mroe convenient way like:-

    Resources
         Keep track of key resources: planned versus actual;
            * number of developers
            * number of customers assigned to the project
            * number of testers
            * number of computers in development, test, production

    Scope
        Keep track of the number of stories over time:
            * how many exist
            * how many are done
            * how many more are expected
    Quality
        Use a standard acceptance testing graph showing
            * number of acceptance tests
            * number of succeeding over time
    Time
            * Track the results of each release plan.
            * Graph schedule versus time.
            * Discuss dropped or added functionality and its impact on time.
  5. 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.

    <strong>This is the start of an excellent and good discussion at Serverside.com about the nature of planning in the XP-eXtreme Programming methodology</strong>. 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 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 XP'ers 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<strong> might</strong> participate in the project.

    Yet the Feasibility Study and Requirements Planning phases are the ones most in need of XP's 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". Nor have I found an explicitly delineated method for doing this sometimes difficult and (as an English bloke said it) <strong>potentially bloody contentious process</strong> 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 XP. BRAVO!

    XP's contribution to IT project management and agile methods has been enormous. Test/measures-first driven development, let no developer be left behind with 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 accomodate 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.