Channels ▼
RSS

Design

Agile is Relative


Flexibility Scales

Once you get beyond all of the myths and recognize that it's not a black-and-white world, it soon becomes obvious that there is no one single agile strategy that is right for all situations. This is true even in the most simple of situations, let alone in the complex situations that we usually find ourselves in—teams are made up of individuals, people who have their own unique experiences, skills and preferences. The implication is that we need to be flexible in the way that we approach software process—that a single "repeatable" approach isn't going to work in all situations.

This is particularly true when you scale agile software development approaches, and that to do so effectively you need to recognize that there are many factors to consider. Each team finds itself in different situations, and depending on where it finds itself with respect to these various factors will determine which agile strategies to apply and how to do so. The critical complexity factors are:

1. Geographical distribution. Is your team colocated (working in the same room), near located (working in the same building or city), or dispersed to various locations around the world? Your communication strategy will vary; in particular, the more dispersed your team, the greater the need for coordination and interim documentation.

2. Regulatory compliance. Regulations such as the Sarbanes-Oxley Act and the Food and Drug Administration (FDA) statutes will increase the documentation and process burden on your projects.

3. Entrenched policies, people, and processes. The organization in which your agile team works may be very agile, it may be very traditional, or somewhere in between. Development teams will need to be flexible in the way that they work with enterprise support teams, and similarly these support teams will need to vary their strategy depending on the working styles of the various teams that they support.

4. Legacy assets. Does your system have to integrate with existing assets such as legacy databases, shared services, or legacy systems? Not only will your technical strategy change to reuse these assets, you may discover that you need to refactor them to bring their quality in line with what your team is creating.

5. Organizational distribution. Do you have people on your team from different work groups, divisions, countries, or even companies? This will impact the way that you organize your team, how you organize the work, and how you share information.

6. Degree of governance. If you have one or more IT projects underway, then you have a development governance program in place. How formal is it? Does it enable or hinder agile work practices? Does it add additional overhead or does it help to streamline your work?

7. Team size. The way that you organize, manage, and support a team of 5 people is very different than the way you do so for a team of 50 or 500.

8. System complexity. The more complex the system, the greater the need for a viable architectural strategy, although that doesn't necessarily imply the need for onerous documentation. Many agile teams adopt the Rational Unified Process (RUP)'s strategy of envisioning the architecture early in the lifecycle and then immediately proving that it works via the creation of an end-to-end, working skeleton of the system.

The values contained in the Agile Alliance's Agile Manifesto (www.agilemanifesto.org) implicitly promote the concept that agile is relative, yet it seems to me that we often forget this in practice. More and more we're applying agile approaches at scale and we're finding that we need to be flexible in our approach. We're also finding that at scale, we need to move towards the right-hand side of the agile values more than some agile zealots would prefer. The agile strategies that worked for small, colocated teams developing straightforward systems won't work very well for large, dispersed teams working in regulatory environments on very complex software. Different situations require different strategies, and the best advice that I can give is to embrace change.


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.
 

Video