Channels ▼


Agile at 10: What We Believe (Scott Ambler)

The Elephants in the Room

Late in the morning, we recognized that there were several issues we were avoiding in our discussions. This avoidance was due in part to the prevailing culture of the agile community, in part due to commercial interests of several people in the room, and in part because we were originally asked by Alistair to play nicely together. So we invested some time to identify these "elephants in the room" so that they could be discussed. I've listed these below so that you can hopefully gain better perspective as to some of the issues holding back the agile community. These issues are:

  • There are other effective ways of information discovery without writing code — Agile modeling, for example.
  • Managers and management are bad — This is a common refrain of many programmers, including agile ones.
  • Politics within the community — There are many factions within the agile community, they don't always agree nor do they even get along.
  • Failure to dampen negative behaviors — We often promote good behaviors within the agile community, such as allowing requirements to emerge over time, but do not push back sufficiently against poor behaviors such as documentation-based governance strategies.
  • Technical debt — Are we really paying down technical debt within organizations or merely talking about it?
  • Anarchism — Some of the alliances/organizations within the agile community purporting to be open efforts are little more than Ghaddafiesque groups in practice.
  • Hypocrisy — The reality of agile is often very different than the reality, something I've explored over the years via DDJ surveys.
  • Context and applicability — Many agile strategies are promoted as if they are the best way of doing something, yet in practice, they prove to work well in some situations but very poorly in others. The Agile Scaling Model (ASM) is a contextual framework that may be used to address this problem.
  • Context gets in the way of dogma — Related to the previous point (Context and applicability), it's uncomfortable to admit that your best strategy isn't the only effective way of work, nor always the best.
  • Certification — As I pointed out in January, the agile community continues to build up integrity debt by tolerating questionable certification schemes.
  • Pretending agile is not a business — ‘Nuff said.
  • Abdicating responsibility for product success (to product owners) — Scrum's product owner concept is useful in some contexts, but in practice it is a very difficult role to fill and reflects a serious lack of understanding as to the difficulty surrounding requirements management activities.
  • Agile Alliance — The AA showed great promise years ago and could potentially have lead the way in a true paradigm shift within IT, but in recent years has done little more than organize the annual Agile conference in the United States and provide funding for local agile events.
  • Role of architecture and design — Agile strategies for architecture and design modeling have been long overshadowed by programming practices and Scrum certification.
  • Self organizing teams — The 2010 "How Agile Are You?" survey found that only 56% of "agile teams" were self organizing, and indication that many organizations are still struggling with this concept.
  • Elitism — The agile community needs to find ways to be more welcoming to project management professionals, data professionals, software architects, and other specialist communities within IT.
  • Business value (what is it?) — We sure do talk a lot about providing business value, but don't seem to have a good handle on what it actually means.
  • Scaling naivety — As I show in my work around the ASM, there's a bit more to scaling agile than addressing the issues around large teams and geographically distributed teams, and it's certainly more complicated than holding a "Scrum of Scrums" to coordinate everything.
  • Commercial interests — Perhaps we'd see more evolution in agile methods if we weren't so focused on charging people to get certified in them.
  • Sensing failures — Although DDJ's Project Success surveys over the years have found that agile project teams enjoy a higher success rate than traditional project teams it isn't that much better and we don't have a perfect track record.
  • How do we know that we're delivering value through software? — If we can't define value surely we must also be struggling to measure it as well.

The four belief statements are not meant to be an addendum to the Agile Manifesto. Several of us, myself included, felt that the manifesto should be updated to reflect what we've learned as a community these past ten years. An equal number within the group, however, felt that the manifesto shouldn't be updated. It was clear that we wouldn't reach any sort of consensus on this issue, let alone on what the changes should be, so we decided to leave well enough alone for now. Interestingly, many of the "elephants in the room" could begin to be addressed by improvements to the manifesto. Go figure.

Further Reading

For more information about the event, visit the 10 Years of Agile site at

I discuss The Agile Manifesto in detail in my article "The Agile Manifesto Examined" and suggest several improvements in "Reworking the Agile Manifesto."

My January 2011 Dr. Dobb's article, "Certified Scrum Master Examined,", summarized the results of a recent survey exploring what people really think about the CSM.

The Disciplined Agile Delivery (DAD) is a hybrid process framework capturing strategies from Scrum, XP, Agile Modeling, lean software development, Kanban, and other agile/lean sources.

Scaling Agile: An Executive Guide (PDF) is a paper I wrote that explores the issues surrounding agility at scale.

The Surveys Exploring the Current State of Information Technology Practices page links to the results of all the DDJ surveys that I've run over the years.

My [email protected] blog discusses strategies for adopting and applying agile strategies in complex environments.

You can follow me on Twitter.

— Scott W. Ambler is Chief Methodologist for Agile and Lean at IBM Rational.

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.