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

Design

Imperfectly Agile: You Too Can Be Agile!


Scott is a Canada-based software process improvement (SPI) consultant, mentor, and trainer with AmbySoft Inc. He has authored several books and is a regular speaker at software conferences worldwide. He can be contacted at www.ambysoft.com/scottAmbler.html.


People new to the idea of agile software development think that you can only be agile with small, co-located teams where you have no political constraints. Yes, that's ideal, but most teams aren't lucky enough to be in that situation. Does that mean they should give up on agile techniques? No! It means that they need to be smart about how they apply agile concepts and be as agile as possible given their current situation. This month, I explore strategies that people have used when they found themselves in not-so-ideal situations.

Dispersed Agile Development

In June I participated in the Perspectives on Systems Informatics at Akademgorodok, Siberia where I ran a tutorial on agile software development. After the tutorial, a couple of people came up to me and said this agile stuff was great in theory, but that it wouldn't work for them. One person worked in an outsourcing company where their clients were in Europe, and another worked for a company where the development team was split between Copenhagen and Moscow. Both were convinced that because their team wasn't co-located that they couldn't be agile. Nothing could be further from the truth.

Ideally, you want to co-locate your developers and stakeholders to improve their ability to collaborate and communicate, thereby reducing cost (they don't need to document as much) and risk (you increase the chance that they understand each other) on your project. In practice, many teams find themselves in a dispersed, multilocation environment and must find ways to overcome the inherent communication barriers. In "Bridging the Distance" (www.ddj.com/dept/architect/184414899), I describe strategies for doing exactly that. Dispersed agile teams will begin a project together so as to build a common vision, will get together occasionally to fortify that vision, and will have people traveling back and forth between locations as needed. They'll also adopt collaborative tools such as chat software, desktop sharing software, and Wikis. They'll communicate with each other via e-mail, telephone/video conferencing, and (egads!) even some written documentation.

Large Team Agile Development

As I describe in "Supersize Me" (www.ddj.com/dept/ architect/184415491), it's possible to have large agile teams. In fact, the first Feature Driven Development (FDD) team was 50 people and the second was 150 people—and both projects were a success. It's quite common to hear about agile teams of 30 or 40 people, and one of the most successful software development teams in history (see the sidebar "Large, Dispersed, Complex, Political, and Yet Still Agile") is much larger than that (and they're agile).

Large agile teams typically follow several common strategies.

  • First, they organize themselves into several small, co-located subteams.
  • Second, they model their requirements and architecture at a high level early in the project so as to set a common vision.
  • Third, they deliver working software on a regular basis, often once every four to eight weeks, to ensure that the subteams are working toward the same goals.
  • Fourth, they coordinate their efforts via regular communication.
  • Fifth, they hire good people with the skills to work effectively with others and to produce actual working software.
  • Sixth, they adopt common philosophies and guidance (such as coding conventions) to support consistency within and between the subteams.


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.