For over a decade I wrote a monthly column, the occasional feature article, and towards the end a blog for the now defunct print magazines Software Development and Dr. Dobbs Journal. In February 2011 I wrote an blog entitled Agile at 10: What We Believe, which described what happened at the workshop celebrating the 10th anniversary of the writing of the Agile Manifesto.  The original article is no longer available online, the DDJ site has unfortunately degraded over time, but here is the original text that I submitted to the magazine back in 2011. I believe that this meeting was an important part of agile history, and this was one of the few records of what happened.

========

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 newsletter 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 in 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, as various DDJ surveys have shown over the years 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 believe 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 actively life-long learning, 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, to post ideas in blogs, to tweet, to 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 that 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 to name a few. 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 they called around to the confirmed attendees to discuss what they wanted to achieve when we got together.  We first saw the results of this the night before when we gathered in the evening for drinks and discovered that index cards containing questions 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 12^th, 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 with sticky notes identified issues pertaining to that category.  Then the subgroups rotated to the next category to review the previous work and to add any new ideas that were missed previously.  We proceeded iteratively until each subgroup had contributed to each topic category.

Over the break several of us chose to go skiing, the weather was perfect and the mountain offered a range of challenging ski runs – if you downhill ski then I highly suggest Snowbird.  In parallel many people decided to continue discussing the issues identified during the morning session.  The facilitators also took the opportunity to organize our work and to prepare for getting the group back together that night.

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 that we 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 the 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.

The Elephants in the Room

Late in the morning we recognized that there were several issues that 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 issues below, using the format of “elephantine issue – my thoughts on the subject” 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 promoting 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 one best way of doing something, yet in practice they prove to work well in some situations yet very poorly in others.  The Agile Scaling Model (ASM) is a contextual framework which may be used to address this problem. NOTE: The ASM evolved over the years into way of working (WoW) context factors.
• Context gets in the way of dogma – Related to the previous point, it’s uncomfortable to admit that your one 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 many 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.