Here’s the final of four podcasts on agile software development. If the first three got you buzzed about cutting code the agile way, and you’re pumped up to do it, and you’re just bursting to get out the gate … this one will make you think twice. It’s not all roses you know! In the spirit of pragmatism, it’s important to be aware of the strengths and weaknesses of many different approaches. So this podcast looks at the flaws and challenges for agile software development.

Click to download the podcast mp3

This is a Podcast. On Internet Explorer, Click the left mouse button to listen, or click the right mouse buttton and “Save As…” to download. Better yet, you can subscribe for updates straight into your PC or ipod - it’s easy and free. Install the free, open-source, Ipodder client and when it starts, just paste this in: “http://www.softwareas.com/wp-rss2.php”. Too easy! 15 minutes and you can be subscribed to receive thousands of MP3 podcasts - straight to your PC as soon as they’re published. And also your IPod if you have one, or you can listen on any other portable player. More info in the Podcast FAQ.

Show notes for this podcast:

  • Methodologies: Pragmatic good, dogmatic bad.

  • Sources: * Personal and others’ views and anecdotes. * McBreen’s Questioning Extreme Programming * Stephens and Rosenberg’s [Extreme Programming Refactored] * Polite commentary and outright flame wars on forums such as Usenet.

  • Non-starter problems: (traditional complaints where agile has reasonable comebacks)
    • How can we keep quality high if the software keeps changing?
    • What if staff leave?

  • Open problems: (further complaints which I feel still need to be answered):

    • Limited project size and criticality
    • Continuously changing non-functional areas
    • Gathering requirements without business analysts
    • Can be more demanding: more social interaction. (see Kathy Sierra’ blog entry on pair programming and loner personality types).
    • Might work for developers, but does it fit with external stakeholders (managers, clients, auditors, users)?
    • Billing model: time-and-materials versus fixed-contract.
    • Flatter structure: how about less talented or motivated staff?
    • Can be used as an excuse for hacking (not a criticism of agile per se, but where’s the boundary?)

  • XP-specific problems:

    • Fragile: Can’t always apply all practices, and leaving one or two out can cause project to collapse
    • Why always pair? Some tasks benefit more than others.
    • Collective ownership: who’s responsible?
  • Discussion:
    • (With apologies to Churchill) For many typical projects, agile may be the worse methodology … except all the others.
    • Moreover, avoid direct comparisons and be pragmatic: Treat methodologies as a palette of tools and techniques. Know them well, and take on whatever fits your current needs.
  • Agile Series Wrap-Up.