Opinions over the usefulness and suitability of agile or extreme programming are diverse, but they tend to converge at one point: Few believe that XP is suitable for large-scale development initiatives. However, XP’s most useful virtues may be wed to those of other methodologies to create an attractive candidate methodology for large-scale projects.
XP’s principal weakness is its emphasis: It is very strong on programming techniques for rapid deployment and is, conversely, very weak in management techniques and project controls. What is needed to bring XP’s deft programming practices to large-scale projects is a managing framework that will accommodate its strengths.
XP for programming; DSDM for project controls
The Dynamic Systems Development Method (DSDM), a European standard supported by a worldwide consortium, offers such a framework. Created for the same purpose as XP—rapid development and testing of user-driven business systems—DSDM has much in common with its leaner, meaner cousin. They share these features:
- Proactive participation of users/customers in the development process
- Team orientation, with participants organized in small groups
- Limited available time-to-delivery
- Clear prioritization between “must have” and “would be nice”
- Modification of the developing system in incremental steps
- Immediate feedback on all changes to the developing system
- Continual testing during prototyping/development
Flying solo with XP: Potential storms
XP’s primary techniques for rapid hands-on development are pair programming and perpetual testing. Each of these features has obvious virtues, but they are also hazardous when attempted on a large project.
Pair programming is intense by nature. Sitting programmers down together to face the same problem, day in and day out, is exhausting and runs counter to the personalities of many programmers, who prefer to crawl into a solitary hole to do their thinking. For limited periods, programmers can suffer through this technique because of its usefulness. However, the process can break down easily when a team faces a long-term project or multiple portions of a large project in series.
Similarly, daily testing of components in process can be wearying and can lead to errors and frustration. XP relies on this technique to achieve an accurate end product under severe time constraints. However, large-scale projects contain vast numbers of components, and daily testing of every component under development can break down under combinatorial pressure, consuming far too many resources.
To be able to achieve the same end by modifying these techniques can make all the difference in terms of XP’s applicability to a project. DSDM provides an out in each case. The purpose of pair programming is perpetual review of code to stop errors before they happen. DSDM offers front-end review processes that lessen the need for such review, so that programming teams can find ways to work that suit them best. And DSDM’s testing paradigm is organized in structured phases, so that component testing is staggered, thus minimizing the daily testing burden.
Opposite methodologies attract
As in any good relationship, these two methodologies have strengths and weaknesses that are complementary, each making up for the other’s deficiencies. The result is a strong, robust toolkit that is well suited to broad, complex development work.
XP provides little in the way of project controls. When a project is small, this shortcoming doesn’t present a major difficulty. As project size increases, of course, so does the chance of running amok if solid controls are not in place. This weakness must be overcome for large-scale applications. XP is, in essence, a toolkit of techniques.
DSDM’s weakness is its lack of techniques for getting programming done, and done well, in the tight time frames its controls provide for. It contains few useful best practices guidelines for hands-on work. It is, in essence, a framework for project management.
XP is focused on coding; DSDM is focused on system life cycle. Combining these focuses allows a team to get its arms around a hefty programming burden without sacrificing quality.
In “Eight reasons why extreme programming won’t work in your shop,” the criticism is made that XP can break down in practice because it demands a certain maturity of its development team members, a discipline that must exist because the development framework itself does not inculcate or enforce methodical discipline. DSDM shares the philosophy that quality is the responsibility of the development team, not management, but compensates for XP’s lack of discipline with very clearly defined roles and built-in quality enforcement by creating an in-team accountability path.
Similarly, XP leaves the definition of specific responsibilities open, precisely to accommodate small projects. With DSDM, putting defined responsibility back is a simple matter of assigning the coordination roles it specifies.
Putting testing to the test
The importance of cyclic testing to any RAD process can’t be overstressed. Both XP and DSDM allow for continual testing. A marriage between the two approaches can bring large-scale projects into the practical realm.
XP’s testing strength is its insistence on setting up test cases prior to coding. This is a terrific way to take targets already made clear from a business standpoint and make them more easily achievable at the nuts-and-bolts level. The problem, when scaling up, is combinatorial proliferation: too many test cases to keep up with. As stated above, DSDM eases this burden by staggering this testing across phases. For instance, it can be set aside in the beginning stages of prototyping, and need not be done daily or even regularly until the midproject iterative phases begin.
Further, DSDM calls for project-specific testing paradigms, so that the testing strategy is defined early on and is specific to the project, rather than XP’s test-it-because-it’s-that-time-of-day approach. On the other hand, if testing components continuously is situationally appropriate, DSDM provides the necessary management controls.
The right tool for the right job
Development methodologies aren’t rocket science, but neither are they interchangeable. Selecting a good method, or creating a hybrid, is never simply a matter of preference. Responsible project management is a matter of careful review of requirements and painstaking selection of the right tools for the job. XP and DSDM, as project development toolkits, offer many useful tools that work well together. Selecting and using them is, as always, a matter of solid planning and thoughtful execution.