Ipod, Podcasting, Peas in a Pod and best of all...

Hands up anyone who's heard of 'pod based development'....

Anyone?

Anyway, the methodology is quite simple. One member from each of the teams working on the project get together, and work towards completing a small piece of work. So - start the recipe by breaking work down into its key components. Throw in one tester, one member from the user team, one member of the vendor team, and someone from infrastructure. Mix together around a table, and, following the effervescent thoes of several people trying to keep their workload down (or, more appropriatly, keep their workload from getting even larger), the assigned thread of the application can be defined, designed, and developed. The key deliverable is the test script that will give the thread a seal of approval from the control board (aka the pod bods).

To use our implementation as an example - the project was fairly far down the line. Development was slow - too many groups working with communication at the 'scarce to none' level. An underestimated testing cycle resulted in the project running behind schedule, which of course goes hand in hand with the project being over budget. Full credit has to go to our project manager, who suggested this approach, and as no one (especially senior management) appreciates change deep in a project, credit has to go to the management team for embracing this approach. Although too early to state any clear improvements, the increased level of inter team communication (one could say that all distinct teams are now part of the same pod), the opportunity to be questioned from members of the team that would have otherwise not been exposed to the application until further down the line (or alternatively, would have stopped being involved with the project at this point), and the growing optimism and confidence in the project can surely be witnessed by the management team.

It goes without saying the approach is not without issues. Looking at one area/thread of the application in isolation is like trying to pull out a single thread from a tangled web, with so many dependencies it seems that the task is just grey areas from other parts of the application. It always feels as if there's an indemnity clause by the fact that areas of the work one's pod should be doing should also be covered by the work another pod may be completing.

I'm sure you're all waiting with baited breath for updates on this, I'll keep you up to date with progress....in the mean time, if you'd like to get further acquainted with this approach, and other agile software development methodologies....

* wikipedias entry on agile development
* martin fowlers 'the new methodology'
* 'scrum' based development