Many IT project managers I know are asking this question: How do Agile and SCRUM methodologies square with “traditional” PMIBOK practice? And as a side topic – how will PMI adapt this, because Agile and SCRUM are being used in the “real world” and fighting it as a traditionalist project manager can make you irrelevant in a hurry.
The second issue is how this gets applied in high-volume transactional systems where, in essence, you can’t take a chance on dropping a transaction or fouling a transaction with a minor XML schema change.
I am assuming that most practicioners of these methodologies are either not in high-volume financial and transactional environments (and subject to very strict audit requirments for change management) or are doing this development on test systems that emulate the production systems. Not on a live production environment. This is never stated explicitly,
This second point is important in the transactional world because it can be very costly (even with virtualization) to emulate the production environment in the development/QA environment to the degree that “believable” load testing (along with rapid full and partial regression testing in the final acceptance stage) can be done. It’s an issue I’ve had to grapple with more than once as applications that flew through a short, but highly iterative cycle blew sky-high in production. Customer loved it in beta and wanted to kill us after we hit production and then had to roll back to a prior version. Problems were fixed within hours, but banks and trading firms have extremely low tolerance for failed transactions or slow confirmation reporting (or even having their logo dropped from the website, etc., etc.).
As for XP – If you have the headcount, do it (or at least try it). I love it, but it has its cost and productivity implications. It’s been very difficult to justify the “apparent” drop in productivity per engineer in a straight line to the better designs that have less initial defects that XP can achieve. There are also the “personal space” issues that sometimes require changes to the physical office environment. Anyone had experience with “pods” where the cubicles or workspaces were arranged in a fashion with the engineers facing “into” their cubicles, but able to swing around to a “meeting area” at the center when it came time to do their shared work?
