Channels ▼

Duking It Out Reloaded

Agile CMM?
Watts Humphrey, best known for his work on the Capability Maturity Model (CMM), kicked off the conference with a keynote presentation examining the "religious war" currently raging in the software community. He pointed out its futility, stating that we'll never agree on a single way to develop software, because it's so rich and varied that each project requires a mix of skills and practices. He also overviewed the Personal Software Process and the Team Software Process (neither of which, in my opinion, are agile, although they are good options when you need a rigorous approach). Although he admitted that he was still learning about agile software development, Humphrey made several important observations that can benefit everyone. First, regardless of what your project stakeholders may tell you, what they really want is a system for no cost right now—everything else is a compromise. Second, if you don't make your own schedule, somebody else will. Third, if you don't consistently meet commitments, you won't have credibility, and without credibility, you can't manage your own work.

The Lake Wobegon Effect
Barry Boehm followed with another keynote that detailed his experiences with agile software development, making the vital point that too many people worry that agile processes won't work with "below average" staff. Claiming that everyone is "above average" at something, he suggested that perhaps the problem may lie not in your staff itself, but in your manner of organizing them.

Breaking Barriers
Martin Fowler, author (with Kent Beck and John Brant) of Refactoring: Improving the Design of Existing Code (Addison-Wesley, 1999), a 2000 Software Development Jolt Productivity Award winner, also presented a keynote at the conference, discussing the ubiquitous question "What makes agile development so different?" and focusing on agility's attitude toward people and change. Agile methods are people-focused, fostering effective communication and actively breaking down barriers between people, he claimed, and agile proponents accept and revel in the fact that change happens.

One track of the conference was dedicated to Harrison Owen's open-space technique, a meeting methodology that explores a theme of importance to the participants, an open invitation for anyone to join and no preset agenda. Open space is based on four principles: Whoever comes are the right people; whatever happens is the only thing that could have; whenever it starts is the right time; and when it's over, it's over.

About a third of the conference-goers attended the first day of the open-space track, which began with a quick description of the technique. In this session, people were invited to suggest a topic and to choose a predefined time slot and location at which to discuss it. The time slots were 90 minutes long and the locations were spread throughout the conference area. More than 20 topics were initially identified, with more added as the conference progressed.

The open-space effort puts control of a significant portion of the conference into the hands of the attendees. We didn't have to rely on what the conference committee decided we needed to see—instead, we introduced our own topics and worked together to explore them. The open-space approach really helped to fill in the holes: Those topics in which the conference was weak, such as requirements/analysis, modeling and testing, garnered several open-space discussion groups.

At breakfast on the second day, I was sitting with some folks talking about their experiences. Everyone loved open space, and one person said that he regretted not attending any of the discussions the first day because he initially thought that open space sounded too flaky to actually work. I pointed out that this is exactly what some people think about agile software development techniques: Many will wait and see if something works instead of trying it right away; therefore, as change agents, we need to learn to be patient.

Sabbaticals for Recovering Developerholics
During the conference, I spoke with Rational Corporation's Gary Pollice. I had hoped to discuss some RUP issues with him, but instead we started chatting about personal stuff and came up with the idea of supporting sabbaticals within the IT industry. Perhaps a developer could work in a business division, at a partner organization, or simply return to school for a semester. Sabbaticals like this could prove to be a great way to recharge batteries after a difficult project.

Alistair Cockburn, author of Agile Software Development (Addison-Wesley, 2001 [winner of a Software Development 2001 Jolt Productivity Award]) and Ron Jeffries (webmaster of ended the conference with keynotes. To emphasize the absurdity of the religious war described by Watts Humphrey, Cockburn used the analogy of the "Great Bunny Ear Debate": What's the proper way to tie your shoes? Instead of focusing on meaningless quibbles, Cockburn recommends that you pick the right base process and then tailor it accordingly to reflect your needs; one process size does not fit all. Jeffries discussed the raging debate about traditional big design up front (BDUF) approaches and the emergent design methods favored by agilists. To BDUF proponents, he made what I call the "Jeffries Challenge": Show him a system with high cohesion and low coupling, the result of proper emergent design, that is vulnerable to change. He's betting—and I agree—that no one will be able to do this.

Communication and Cooperation
The most important aspect of a conference is the people who attend, because they're the richest resource of all. The traditional conference is a collection of presentations, a relatively cold form of communication, but the agile community chose to eat its own dog food—with extreme enthusiasm—by promoting interactive conversations among all participants. Kudos to XP gurus Chet Hendrickson and Ann Anderson for organizing the open-space effort. The experiment was a success.

Scott W. Ambler will be leading interactive workshops about agile software development techniques, including both Agile Modeling (AM) and Agile Data (AD), at SD East in Boston Nov. 18-22 (

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.