I tried answering Tad Anderson’s comment within the bounds of my August 8^th posting but eventually decided that this topic really warranted a posting of its own. My thoughts around using Extreme Programming and other Agile approaches to software development are pretty well formed. As an ex-soldier, military analogies seem to work particularly well for me:

• On the high end, the truly capable XP team is small, lightweight, and meets the requirements Tad set forth in his post. In many ways, effective Agile teams parallel our military’s elite special forces (e.g. SEALs, Green Berets, Delta Force, etc).
• In the middle, there are well-trained, capable teams that practice UP, ICONIX, and other iterative processes with varying degrees of agility. These teams may infuse certain XP practices into their process as they are needed. The individuals on these teams may have the mettle to be elite special forces. However, due to project requirements, team size, or other factors they are not “active operators”, in military parlance. These folks operate in a fashion analogous to our highly-skilled tactical units, such as the 82^nd Airborne, 10^th Mountain, and the like.
• On the lower end (of the agility scale, that is) are teams that mirror our more traditional Army units: infantry, mechanized infantry, armor, artillery, etc. Their capabilities are more geared toward larger, more structured engagements. Backing these capabilities are detailed approaches and tactics, significantly greater support and infrastructure requirements, and longer lead times to get a team on the ground to effectively engage the problem.

So where does this leave us? To me, at least, it’s pretty clear that, on software projects, as in combat, there is no one-size-fits-all approach. I would no more likely try to tackle building an air traffic control system with XP than I would send in a special forces team to face off against a Soviet armored column. Analogously, I would neither call in the third armored division to handle a jungle-based guerilla insurgency nor try to use CMM level 5 processes to build a simple Web-based e-commerce application.

Deciding what type of software development process to use is ultimately a managerial responsibility. From this decision, to paraphrase a saying, will come 90% of your happiness or misery. Making the right decision requires that the manager has an intimate understanding of his team’s capabilities, understands the scope of the project, and has correctly assessed the level of involvement that can be expected from project stakeholders. This knowledge is, by no means, easy to come by; which helps explain why there is so often a dissonance between the approach applied and the one required. Just like with a SEAL team, there are limitations on the number of individuals that have the raw capabilities to be effective members of an Agile A-Team. If you done an honest assessment and are certain that the Agile approach is right for the project and you have an A-Team, then go for it.

As a footnote, this military analogy brings to light interesting questions of contingent or complementary force parallels in software engineering. That is, Operation Iraqi Freedom was fought with a mix of closely coordinated heavy armor, airborne, and special forces units. I can imagine that within an enterprise, or even within a project, there might be room for similar collaboration between high ceremony teams, medium-weight iterative teams, and light-weight agile teams. I’ve started to see the first signs of this on projects and would be interested to hear your take on this.