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

The Threat of the New

, December 01, 2001


December 2001: The Threat of the New

This year it was hard to avoid the buzz about agile processes, but it will take some time for agility to permeate the industry. We're at the beginning of a paradigm shift, one that will likely have as great an impact as the object-oriented phenomenon of the past 20 years. Some developers feel threatened by agile processes. Why?

In some cases, it's reasonable doubt, because not all of the agile process message makes sense to everyone. Initial skepticism is healthy, but I'm concerned about the rising level of anti-AP misinformation and rhetoric. The negative reaction stems from the fact that agile processes are new and unfamiliar, and require changes in personnel, process and culture.

The Great Unknown
Much resistance is caused by misinformation. If you want to learn about agile processes, go to the source because, pro or con, magazine articles just aren't enough. I've put together a list of agile resources at www.agilemodeling.com/resources.htm. Research alone isn't sufficient, however: You should actively try something before you attack or applaud.

Many people criticize agile processes because they probably won't work in their own environment; therefore, they proclaim they won't work anywhere. To my knowledge, no one has ever claimed that agile processes work for all situations. In Extreme Programming Explained (Addison-Wesley, 1999), Kent Beck indicates the conditions to which he believes XP is applicable. I do the same for Agile Modeling (AM) at www.agilemodeling.com.

Despite the success stories, a few critics aren't willing to try agile methods—they'd rather wait for more evidence. And that's fine: Not everyone needs to be an early adopter. I only ask that detractors remember that it will probably be a few years before significant studies are performed.

People also fear the implied personnel changes. In an agile world, developers need broader skills. For example, XP developers are expected to work closely with their users, to write both business and testing code, and to build and deploy the system. Furthermore, XP's focus on building software is particularly threatening to those who haven't written code for some time. Even AM, which focuses solely on modeling, demands an understanding of and ability to apply a wide range of models, certainly more than those described by UML or by traditional structured analysis and design. Don't get me wrong—agile processes don't require you to have all of these skills at the starting block, but you should be willing to learn.

Agility also depends on increased communication. XP, for example, insists that you pair program and have an on-site customer; AM demands that you seek active stakeholder participation and warns you that development is dangerous to do alone.

Your Approach Changes
Agile processes challenge many software process concepts that developers may take for granted. For example, an iterative and incremental approach to development, one that prizes the production of working software over documentation, can be threatening to anyone whose primary aim is to create detailed architectural models or project plans. This also threatens those who prefer to document all, or most, of the requirements before beginning to model and code. Agile doctrine, on the other hand, advises fleshing out a few high-priority requirements and implementing them fully before moving on.

Because agile developers need a broader skill-set, and their projects require increased communication, there is less need for hand-offs between teams. In fact, this cooperative environment often negates the need for formal, detailed design models; often, a hand-drawn sketch is sufficient.

If you're no longer handing off artifacts between teams, artifact review becomes far less important. Your project stakeholders will still need proof that you're moving forward, but if they're active participants, they should know the status.

The elimination of non-value-add (NVA) activities forms a common thread among agile processes. Mary Poppendieck, author of "Lean Programming" (May and June 2001), recently pointed out on the AM mailing list that many people don't recognize NVA activities for what they are. It's only natural that those who perform the activities feel threatened.

Culture Shock
Agile processes also demand an atmosphere of mutual trust. XP is interesting because it specifies that developers make the technical decisions and customers make the business decisions. For example, developers can estimate the effort to implement a requirement, but aren't allowed to assign it a priority, as business decisions are the customer's responsibility.

In the agile world, project members' roles and responsibilities are changing. Managers should coach and empower staff, remove roadblocks, actively participate in development instead of relying on status reports, and bring food to their hardworking developers. Agile roles for users are changing, also: They must actively participate in projects and not just attend the occasional review.

Cultural challenges are perhaps the toughest to overcome, and many people have given up trying to fight the cultural inertia of their company. As Martin Fowler first said in his keynote address at XP 2000, "If you can't change your organization, change your organization." Sometimes your best option is to find employment elsewhere.

On the other hand, if your organization is effective at developing software, it might be best to stick with what you are doing. You may want to instead consider the Unified Process. Not everyone needs to be agile.

Time Will Tell
I equate the agile paradigm shift to the object paradigm shift—although OO was first proposed in the late 1960s, it was initially adopted by the business community in the late 1980s and popularized in the 1990s. Agile processes, arguably with origins in the Rapid Application Development movement of the 1980s, were initially adopted in the mid-1990s with Scrum and DSDM, and are just now being popularized with XP. We're only partway along the agile paradigm shift—but agility is here to stay.

I'd like to thank the following people for their valuable insights: Tony DaSilva, Dale Emery, Michael Feathers, Martin Fowler, Juan Garcia, Ron Jeffries, Joe Klemke, Angela Martin, Randy Miller, Mary Poppendieck, Kendall Scott and Geri Winters.

Resources on the Web
Manifesto for Agile Software Development www.agilealliance.org
Agile Modeling mailing list www.agilemodeling.com/feedback.htm
Agile Modeling newsletter A monthly e-mail digest of discussions and links, edited by Scott Ambler. Subscribe at www.sdmagazine.com/newsletters/.


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.