Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Methodological Agility

, June 01, 2001


June 2001: Methodological Agility

Software development today can seem like a strange game. At one end of the field, in scruffy jerseys of assorted color and stripe, lurk the unruly rabble representing the methodless chaos that all too often passes for programming in many organizations; at the other end, we see the advancing phalanx of the heavyweight team, a bright letter U emblazoned on the chest of each hulking Goliath. These true heavyweights of modern software development—the Unified Process and its supporting player, the Unified Modeling Language—were subject to critical scrutiny recently in Management Forum ("Unified Hegemony," Nov. 2000).

Between the contrasting extremes of libertarian license and methodological muddling, the center of the process playing field is currently dominated by the real crowd-pleasers of modern software development: a small group of relatively young, fast-moving players—the so-called lightweight processes, with names like XP, Crystal, SCRUM and FDD. To be both correct and au courant, however, we should follow the lead of a group of the foremost coaches and promoters of these processes who met in February at Snowbird, Utah, to discuss their current interests and future prospects. Wishing to shed the negative connotations of the term lightweight, they agreed to hereafter refer to their sundry methods as "agile" processes. Agile it is, then. After all, who would want to risk being considered the 98-pound weaklings of software development?

Agile Players
Managers who want to play today's game need to understand not only the league leaders like RUP, the Rational Unified Process, but also the agile competitors. A complete comparison of all the agile processes is beyond the scope of Management Forum; there are just too many, and they differ in too many details. In any case, Martin Fowler has already provided a concise overview in this magazine ("Put Your Process on a Diet," Dec. 2000), and more detail can be found along with useful links in an expanded version available on the Web (www.martinfowler.com/articles/newMethodology.html). In this column, I'll stick to a management perspective and focus on some of the common pluses and minuses of the agile processes.

The archetype of these agile athletes of software development is XP, short for Extreme Programming (see Kent Beck's Extreme Programming Explained, Addison-Wesley, 2000). Undoubtedly the best known of the agile processes, in many respects it typifies this diverse bunch. Like nearly every other methodology—light, heavy or middleweight—XP and its agile teammates are really mish-mashes of tricks and techniques, plus methods, models and management formulas, along with tools, practices and even a bit of philosophy. Some advocates argue that, because the pieces were all concocted to complement each other, you have to buy the whole assorted package of any given method, but many practitioners simply pick and choose the parts that work for them and toss the bits they don't like.

The hallmarks of XP, as with most of the agile processes, are that it's more people oriented than process oriented, and that it emphasizes flexible adaptation rather than full description. Along with the need for agility, the stress on effective teamwork puts a premium on good management and leadership skills. Success with most of the agile approaches requires particularly close, hands-on management aimed at smoothing the process and removing impediments.

Oddly enough, one of the more controversial aspects of XP teamwork is also one of its best-established best practices: pair programming. Also known as the dynamic duo model, pair programming puts two developers in front of a single screen. By providing instantaneous inspection of each line of code, the technique radically reduces bugs and cuts the overall cost of programming. Pioneered by C/C++ guru P. J. Plauger and popularized by yours truly ("The Benefits of Visibility," Computer Language, Sept. 1992; reprinted in The Peopleware Papers, Prentice Hall, 2001), pair programming is a useful technique with a solid track record.

Philosophy is also a critical component of nearly all the agile methods. XP itself is built around a set of core values: simplicity, communication, testing and fearlessness. (Yes, fearlessness.) Jim Highsmith's Adaptive Software Development, which has also been classified with the lightweight processes, is more framework and philosophy than prescribed practices, especially compared to such precisely delineated approaches as XP or Peter Coad's Feature-Driven Development (FDD).

The rules of the game are relatively simple: Work in short release cycles. Do only what is needed, without embellishment. Don't waste time in analysis or design; just start coding. Describe the problem simply in terms of small, distinct pieces, then implement these pieces in successive iterations. Develop a reliable system by building and testing with immediate feedback. Start with something small and simple that works, then elaborate on successive iterations. Maintain tight communication with clients and among programmers. Test every piece in itself and regression-test continuously.

Although some programmers and their managers may think of agile methods as a license to hack, it should be clear that following the philosophy and practices takes genuine discipline. I have heard some managers refer to XP as structured hacking, and that may not be far from the truth.

The Pros
Perhaps the biggest selling point of the agile processes is their weight. With far less heft than the leading heavyweights, they're easier to learn and master. That doesn't mean that agile processes are easy, any more than it suggests that they can substitute for programming skills and developmental discipline—but it does mean that there is less to explain about the processes themselves.

Reduced overhead is another strong point. Unlike the more heavy-duty processes that emphasize diverse deliverables and numerous process artifacts, the agile processes concentrate on code. Design is on-the-fly and as needed. Index cards and whiteboard sketches take the place of a slew of design documents, and brief, stand-up confabs replace protracted meetings.

Early results are yet another benefit of agile processes. With short release cycles that produce a fully functional system on every iteration, clients can begin using a simplified, working core with limited but useful capability early in a project.

For clients, managers and developers alike, agile methods can offer a major potential payoff in minimal defect injection and leakage rates: the number of bugs created in the first place and the number that sneak past successive phases of development. More reliable code means more up-time and cheaper development, requiring less support and maintenance.

The simple philosophies of the agile processes appear to translate fairly well into practice. Despite—or because of—their streamlined structure, agile processes have worked well in a variety of real-world projects. Tales of success far outnumber sob stories (but, of course!), at least for well-trained teams working on appropriately focused projects.

What Goes Around
What are the risks and shortcomings of the agile methods? Readers who have been around long enough or have a sufficient grounding in the history of programming may be experiencing a strong sense of déjà vu. Some 30 years ago, IBM touted so-called chief programmer teams (see F. T. Baker's "Chief Programmer Team Management of Production Programming," IBM Systems Journal, 11 [1], 1972): small, agile groups headed by a strong technical leader who could hold the implicit architecture in mind without resorting to much explicit design. Applications were constructed with thorough inspection and testing through successive refinements. The objective: To have working code at all times, gradually growing it through successive enhancements into a full-scale working system.

Like XP and its agile teammates, chief programmer teams also enjoyed early victories for awhile, but the model ultimately foundered on the shoals, caught between the Charybdis and Scylla of charisma and scale. Led by gifted technical managers and applied to problems of modest size, the approach worked, but there are only so many Terry Bakers in the world, and not every problem can be sliced and diced into the right pieces for speedy incremental refinement.

The same issues challenge today's agile methods. There are only so many Kent Becks in the world to lead the team. All of the agile methods put a premium on having premium people and work best with first-rate, versatile, disciplined developers who are highly skilled and highly motivated. Not only do you need skilled and speedy developers, but you need ones of exceptional discipline, willing to work hell-bent-for-leather with someone sitting beside them watching every move.

Scale is another problem. When I surveyed colleagues who are leaders in the light methods world, they agreed that the agile processes do not readily scale up beyond a certain point. A few brave XP efforts with teams of 30 developers have been launched, but the results are not yet in. Alistair Cockburn claims that his family of methods, known as Crystal, has been used for larger projects, but the general consensus is that 12 to 15 developers is the workable upper limit for most agile processes. The tightly coordinated teamwork needed for these methods to succeed becomes increasingly difficult beyond 15 or 20 developers.

All the agile methods are based on incremental refinement or iterative development in one form or another. The basic premise is that it's easier to add capability to a compact base of well-written existing code than to build a complete application in one fell swoop. Within the prescribed short-release iterations of agile processes, a small team can do only so much. Systems that total some 250,000 lines of code may be achievable over many such iterations, but a million lines is probably out of reach. Moreover, some projects and applications cannot, for all practical purposes, be broken into nice and neat 30-, 60- or 90-day increments.

What's the Use?
My informants in the agile process community also confirmed what numerous colleagues and clients have been suggesting all along. XP and the other light methods are light on the user side of software. They seem to be at their best in applications that aren't GUI-intensive. As methodologist Alistair Cockburn told me, this "is not a weak point—it is an absence." User-interface design and usability are largely overlooked by the agile processes—a failing shared with the bulk of their big-brother behemoths in the heavyweight arena.

Some, like XP, do explicitly provide for user or client participation in pinning down initial requirements through jointly developed scenarios, known as user stories. However, in keeping with an emphasis on minimalist design and repeated refinement, when it comes to user interface design, the agile processes favor somewhat simplistic forms of iterative paper prototyping rather than model-driven design or thorough forethought. Especially with XP, which relies so heavily on testing, GUI-intensive projects pose particular problems. Testing of user interfaces is labor-intensive and time-consuming; automated user-interface testing is difficult, if not impossible, except at the most elementary level. True usability testing requires repeated testing with numbers of users under controlled settings. User or client reactions to paper prototypes are no substitute and can even be completely misleading—what people will say they like or claim is feasible when they see a paper sketch will often prove unworkable in practice.

Iterative prototyping is an acceptable substitute for real user-interface design only when the problems aren't too complicated, there aren't too many screens with too many subtleties, and a rather pedestrian and uninspired solution will suffice. Software with intricate user-interface problems or for which usability will be a major factor demands a more sophisticated, model-driven approach. This is where usage-centered design enters the picture (see Constantine and Lockwood's Software for Use, Addison-Wesley, 1999).

When Lucy Lockwood and I began developing usage-centered design (U-CD) in the early 1990s, we didn't set out to create a lightweight process. Our philosophy has always been simply to use whatever tools and techniques helped us design more usable systems in less time. We aren't surprised, then, that U-CD is increasingly mentioned in company with the agile processes.

Where usage-centered design parts company from some of the agile processes is in its emphasis on modeling and on driving the user interface design and development by the models. First, we build profiles of the roles users play in relation to the system; these directly inform the task model, which captures the nature of the tasks to be supported by the system. The task model—collections of interrelated use cases in simplified, abstract form—directly drives how information and capability are collected and arrayed on the user interface.

In its most agile incarnation, usage-centered design works some of the same card magic that powers XP (see Ron Jeffries's "Card Magic for Managers," Management Forum, Dec. 2000). We model task cases on index cards, thus keeping them short and sweet to facilitate easy collection and distribution. We shuffle the cards to prioritize them by business and end-user importance. We sort them into related groups that help us construct complete usage scenarios and that guide the collection of user interface components into screens, pages or dialog boxes. The same task cases that steer the user interface design are grist for the programming mill that grinds out the objects and methods that power the software. As always, we focus on user intentions and system responsibilities to help distinguish real user needs from mere wants and wishes. In short, usage-centered design probably qualifies as an agile process, even if it wasn't conceived with that in mind. Moreover, it supplies a critical piece missing from other methods-an effective and efficient scheme for designing highly usable user interfaces.

In this, the final installment of Management Forum, I'll leave you with some simple advice. If you're ready to leave behind both ochlocracy and bureaucracy, then it's best to join the agile few and heed the words of the venerable William of Occam: "It is vain to do with more what can be done with less."


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.