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

Has Agile Peaked?


Agile Scales

A small number of respondents indicated that they're succeeding with agile teams of over 200, and many others are trying Agile teams of 50 or more. People are clearly going beyond the small, colocated team approach described in many of the popular Agile writings. Within IBM, we've delivered products into the marketplace with agile teams of 200 people and have several agile programs of 500 or more people. My point, which I've iterated many times in this column, is that it is possible to scale Agile to meet the real-world needs of modern IT. Furthermore, my suspicion is that in the next few years, it will become clear that Agile scales better than traditional development approaches.

It's critical to recognize that there is more to scaling agile software development approaches than supporting large, distributed teams. For example, regulatory compliance is an important scaling factor for many teams, which complicates software development. Cultural challenges within your organization, such as supporting teams that don't work in an agile manner or legacy policies that don't reflect agile strategies, are also a risk at scale. Enterprise issues, such as enterprise architecture, strategic reuse, portfolio management, and IT governance become more apparent once you move beyond the pilot phase of agile adoption. Leveraging legacy assets, such as wrapping existing systems following a service-oriented architecture (SOA) strategy or fixing data-quality problems in production data sources via database refactoring, is an important scaling factor.

Adopting Agile is Very Low Risk

The survey asked about the success rate of Agile project teams in different scenarios. Colocated teams where everyone, including stakeholders, are in the same work area enjoyed an average success rate of 83 percent. Non-colocated teams where people are in different cubes, perhaps on different floors, or in different buildings, where they could easily get together physically if required, had a 72 percent average success rate. Projects where part of the team was at a significantly different location, such as offshoring situations, had a 60 percent average success rate. We asked about these three different scenarios to try to determine the risk premium associated with team distribution, and as you see it's fairly high—a 23 percent difference in success rates between co-location and being highly distributed. Overall survey respondents indicated that the average success rate for agile teams was 77 percent.

Organizations still in the pilot project phase had an 84 percent success rate when colocated, 72 percent when not colocated, 61 percent with highly distributed, and a 79 percent overall success rate. I was a bit surprised that the success rate for the Agile pilot projects was so high. Usually teams that are trying new techniques run into trouble and the project turns into a "learning experience" for the organization. Part of the high success rate is likely attributable to organizations choosing easier projects to pilot Agile techniques on. Also, better people usually staff pilot teams, so that would lead to a higher success rate.

We also wanted to get a feel for how effective agile teams are in practice, so we asked about productivity, quality, stakeholder satisfaction, and cost. Table 2 summarizes the results. As you can see, Agile teams are reporting significant improvements in productivity, quality, and stakeholder satisfaction, and reasonable improvements in cost. The interesting thing is that the upside of adopting agile approaches is fairly high, yet the downside is low. In short, becoming more agile appears to be low-risk decision for senior IT management.

Factor Improved No Change Worsened
Productivity 82% 13% 5%
Quality 77% 14% 9%
Stakeholder Satisfaction 78% 15% 7%
Cost 37% 40% 23%

Table 2: Effectiveness of agile teams.


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.