Channels ▼


Agile at 10: What We Believe (Scott Ambler)

The Agile Manifesto had its beginnings in a meeting held in February 2001 at the Snowbird ski resort just outside of Salt Lake City. To celebrate the ten-year anniversary of this event, Alistair Cockburn, who organized the original meeting, invited a group of agile luminaries back to Snowbird to discuss the future direction of agile. The original 17 manifesto writers were invited, although not all were able to attend, and I was among the people who did participate. In this article, I discuss what we concluded, how the event was organized, and some of the challenges faced by the agile community.

What We Believe

First, let's jump to what most people will perceive to be the end results. As a group, we agreed on the following four belief statements:

  1. Demand technical excellence
  2. Promote individual change and lead organizational change
  3. Organize knowledge and improve education
  4. Maximize value creation across the entire process

Let's dive down into what these belief statements imply. The first statement, demand technical excellence, is a reflection both of the general values of the working group and also our frustration with what we're seeing in practice — or more accurately, not seeing in practice. The Agile Manifesto exudes the philosophy that technical excellence is critical to your success in the software game, yet this requires both skill and discipline to pull off in practice. Many agile teams do in fact manage this feat — various DDJ surveys have shown over the years that agile teams produce higher levels of quality on average. However, the adoption rate of quality techniques such as test-driven development (TDD), refactoring across all architectural tiers, and following common development conventions aren't as high as the agile rhetoric would lead us to believe. There is room for improvement, and our hope is that this first statement will motivate agilists to do so.

The second belief statement is to promote individual change and lead organizational change. Once again, we've definitely come a long way as a community but we have further to go when it comes to improving our approach to software development. At the individual level I believe that we need to life-long learn, teach people to observe what works for them (and what doesn't) in the situations that they find themselves in, and to then act on those observations. At the organizational level it is important to understand both the mechanics and the supporting human behavioral aspects of change processes and then invest the time and resources to effectively execute on them. One aspect of this is to focus on the organizational ecosystem as a whole and not just on IT — in fact, many agilists are instead still mired in the details of software development and unable to see the enterprise forest for the development trees.

Organizing knowledge and improving education is the focus of the third belief statement. Several people in the group voiced their frustration around the lack of a coherent and consistent agile body of knowledge. In many ways, this is a reflection of our times — the Internet makes it easy for people to publish articles, post ideas in blogs, tweet, write wiki pages, and so on, which in turn promotes a dispersed cacophony of voices. This cacophony can be debilitating when you want resources which support teaching agile concepts, particularly at the college and university level but also at the individual learning level. Heresy aside, perhaps an organization such as the Agile Alliance could start amalgamating some of this knowledge, and even go so far as to create an Agile Book of Knowledge (ABoK). Minimally, it's clear that the agile community could do more to reach out to universities and colleges to help them understand and teach agile more effectively.

Last, and certainly not least, is the fourth belief statement that we should strive to maximize value creation across the entire process. One of the fundamental messages of the Disciplined Agile Delivery (DAD) process framework is that we need to look beyond the software construction focus of the Agile Manifesto to address the full solution delivery effort. But this is clearly not the full picture either as there is much more to IT than solution delivery, and certainly much more to your organization than IT. Some of the greatest challenges that we face with agile adoption are the business issues surrounding IT, particularly when it concerns financial issues such as funding delivery projects, IT governance, and understanding and interacting effectively with business stakeholders. As the lean community implores, we need to optimize the whole, and agile software development is only one small part of your overall organizational ecosystem.

How It Happened

To help bring a bit of transparency to this event, I'd like to briefly describe how it was organized. In early January Alistair Cockburn sent out invitations to a number of people whom he felt had added value within the agile movement over the years. Not everyone was able to attend for various reasons, and perhaps a few people who weren't invited should have been, but from what I could tell he brought together a group who was representative of the overall community. I'd like to once again express my thanks to Alistair for taking the lead on this effort.

Luckily Alistair decided to hire professional facilitators Robert Moir and Janet Danforth to organize the event, and I truly believe that we couldn't have succeeded without the two of them. A few weeks prior to the event, they called the confirmed attendees to discuss what they wanted to achieve when we got together. Then, the night before kickoff when we gathered in the evening for drinks, we discovered that index cards containing questions drawn from these pre-interviews had been distributed around the tables. The goal of the cards was to stimulate conversation, not that we needed any help with that, and to communicate to everyone the range of issues to consider the following morning.

The working session itself was held on Saturday February 12th, with an idea generation session in the morning from 8:30 to 12:30 and a focusing session held in the evening from 5 to 7:30. During the morning session we organized into seven subgroups, and we iteratively addressed seven topics — value; agile backlash/retrospective; technical/agile process; other communities and business/enterprise process; culture; education/training; and the future — which the index cards from the night before had been assigned to. Each subgroup started with one of the topics and identified issues pertaining to that category with sticky notes. Then the subgroups rotated to the next category to review the previous work and add any new ideas. We proceeded iteratively until each subgroup had contributed to each topic category.

The goal of the evening session was to come to a consensus around a statement of our beliefs. To do this, we re-categorized the issues we had identified in the morning into things that we can make good headway on, things we don't know how to address, and things that we believe can't be addressed. For example, better communicating the role of architecture in agile development is something we could make good headway on, whereas the fact that many organizations rate their employees in part based on degrees or certifications is something we'll never be able to address as a community. The issues which we believed could be addressed were clustered by topic, the topics were prioritized, and after much discussion and wordsmithing the four belief statements were identified.

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.



These observations have substance. A lot of agile philosophy is great for internal projects that have no fixed budget, but the theory needs a reality check when it comes to real world fixed price customer projects.

Having said that we've used strict yet pragmatic* agile for these kind of projects with success. Anecdotal evidence from 20 years in the business is that it is a much better way to develop.

*Pragmatic agile is not lazy agile. It's just not militant agile. We might drop a showcase if there's nothing new to show, or demo on a developer PC instead of losing a day to prepare data.