Earlier this month two Agile Manifesto co-authors, Dave Thomas and Martin Fowler, participated in a panel for the GOTO Denmark conference series which focused on ‘A retake on the Agile Manifesto’ that took inspiration from Dave’s recent blog, ‘Agile Is Dead (Long Live Agility)’ that has generated interesting debate and discussion since its release in March.
In this Q&A Dave (commonly known as Pragmatic Dave) explains his thoughts around the panel, his blog and why he believes it’s time to focus less on agile and more on the practical application of agility.
InfoQ: What kept you away from participating in agile events until most recently?
It goes back to the original meeting in Snowbird. I went there because I wanted to be in the same room as all these industry luminaries. In the end, it turned out that we all had roughly the same way of looking at software development, which we captured in something we (somewhat pompously) called the Agile Manifesto.
The manifesto documented a set of personal values—the values of the 17 of us at Snowbird. We had no answers, because it is impossible to create universal answers—context will always interfere with any attempt to be absolute.
As far as I was concerned, that was it. We'd published our thoughts, and then we went back to living those values in our day-to-day jobs.
Over time, some folks wanted to create more structure around the concept of agility, and things such as the Agile Alliance sprang into existence. I wasn't one of those people—I didn't see why we needed an Alliance, or any other body. Maybe I'm just not a joiner.
As I watched from the outside, I saw conferences come and go, and saw no need to change my mind and start attending. By and large, the talks followed two templates. One was the "this worked (didn't work) for us, so you should (not) try it." The second was the touchy-feely "listen to people/personal growth" talk.
The first kind of talk is (to my mind) dangerous. People go to conferences, hear them, and go home to try to apply everything they heard. The result is a dogs dinner of processes which don't support each other, and which people gradually abandon.
The second kind of talk is a bit like the apocryphal Chinese dinner—really good at the time, but by the time you get home it seems to have evaporated.
So, the community went its own way, and I just muddled on. Almost all of what I did was based in the values of the manifesto (because my personal values hadn't changed much in the intervening years), but I wouldn't say I had a methodology.
A year or so ago I got an invitation to speak at an agile conference in India, and I agreed to go. Partly it was because the organizer, Naresh Jain, is doing great things with the Indian software community, and I wanted to support him. And, partly, it was because I'd never been to India. I sold out.
At that conference, I overheard two consultants talking. These are folks who tell other people how to code. One consultant admitted he hadn't coded for 10 years. The other laughed and said he hadn't coded since the late '90s.
At that same conference I sat through a talk on SAFe (the Scaled Agile Framework). I was saddened at the way the word "agile" had become devalued, and how far its use had strayed from our initial values.
And that's why I'm now doing interviews like this one.
InfoQ: Why do you think your recent blog has generated the interest and debate it has – resulting in things like the panel in Denmark earlier this month?
I think there are a couple of reasons. First, I was clearly being inflammatory. Even the title, "Agile is Dead" could be considered a cynical attempt to capture tweethearts.
But something doesn't catch fire like this unless there is fuel. I clearly wasn't the only person to notice the commercialization and dilution of agility, and to feel that we were in danger of slipping back into the process muddle of the '80s and '90s. So I suspect I simply articulated a prevalent view.
InfoQ: In Copenhagen and Aarhus, your talk called for the retirement of the word agile – stating that it is no longer useful for developers in their day to day practice as its been taken over by an ‘industry’ – can you elaborate on that?
To be honest, I think that is probably a weak idea. The original thinking was that the word "agile" itself has been lost to us—it no longer means what we meant when we created the manifesto.
We could try to reclaim it, but that would be virtually impossible for a loosely coupled group of individuals. So I thought "let's just abandon the word." In reality, I've never been happy with the use of "agile" as a noun. In English it is an adverb, a word that qualifies an action. And that's what the manifesto values were all about—doing things.
So the blog post contained a suggestion that we stop using the word "agile" and switch to "agility" as it better describes what we believe.
In retrospect, I'd probably not include that paragraph if I was doing it again. It is a distraction from the real message.
InfoQ: In your intro talk on the panel you appealed to those in technology to re-focus back on what is useful for developers and the people who do the work – how do you think the industry has strayed from being useful to doers?
In the early years of the 2000s, practices labelled "agile" were used by individual developers or small teams. Often these teams and their practices were under the radar. But companies started to notice, particularly when a number of small startups said they used the practices to help them earn their multimillion IPOs.
Gradually, "agile" became respectable. And, as it did, larger companies wanted to participate. I think that is wonderful. However, they were often uncertain just what to do. Managers issued "make us agile" edicts. And so, like sharks drawn to blood, the consultants and consulting companies started to circle.
The advice they gave was designed to be manager-friendly. They included lots of reporting, lots of meetings, and talked about developers as "resources" not "people." And although they probably improved the processes at their clients, I suspect that the improvement was as much due to the Hawthorne effect as to the processes themselves. Long term, these processes will likely decline in efficacy.
But, the reality is that processes that embody the values in the manifesto start at the level of individual developers. You can be working in the most old-fashioned, rigid company, and yet still practice the values in your daily life. And both you and your company will benefit from this.
Maybe a group of you will want to observe the values. Get together and discuss just how you interpret them, and what you do in the way of practices. At that point you have a team.
And maybe, just maybe, multiple teams can get together, discuss their practices, and come up with something more global. And that could be an "agile" organization.
Agility cannot be imposed from the top, simply because good agile practices have to be discovered by the people using them—they cannot be imposed.
So I call for the adoption of agility to revert to the original, effective form. It starts from the people working on the coding coal face, and organically grows throughout the company.
For this to work, we need developers who care. More importantly, we need developers with courage, because they (and their values) will be up against a lot of resistance. Doing the right thing has always been a dangerous practice.
InfoQ: Your presentation in Denmark also outlined a very succinct way to get back to basics– can you firstly explain your suggestion for those who have not yet read your blog? And secondly, elaborate on why you think it’s important we revisit these core essentials, even when it appears to some that the agile industry is ‘successfully maturing’?
Look back at the values:
- Individuals and Interactions over Processes and Tools
- Working Software over Comprehensive Documentation
- Customer Collaboration over Contract Negotiation, and
- Responding to Change over Following a Plan
It is all about feedback—interactions, working software (so you can see if it is what is wanted), collaboration, responding to change—everything is a feedback loop. So let's acknowledge that as the basis of a set of "metapractices".
- Find out where you are
- Take a small step towards your goal
- Adjust your understanding based on what you learned
- Repeat
This is simply a feedback loop. What makes it powerful is that it doesn't contain any actual practices. Instead, as a developer, you have to work out how each step applies in your situation. And, as if that's not enough, you have to work out what the situations actually are. It could be as simple as the naming of the function, or as complex as the plan for a new business. But recognizing the existence of these four steps, and then setting up ways of working that keep them in the forefront of everything you do—that is the only thing you need to know about agility.
Except—real life doesn't have many totally obvious "best ways of doing something." So there's one additional practice:
- When faced with two of more alternatives that deliver roughly the same value, take the path that makes future change easier.
This is what we reclaim. We don't need acronyms, consultants, complex diagrams, conferences and the like. We just have some ideas that can be written on an index card, along with the courage to apply them relentlessly.
As to your request to elaborate on why it’s important we revisit these core essentials, to some extent your question is its own answer. 'The agile industry is successfully maturing.' What does this mean? First, it means the standardization and commoditization of something called "agile." But how can you standardize and productize a set of values? The whole point of values is that they are a compass, not a map. They help you decide on a way to make progress, but only once you know where you are and where you want to go. You can't prescribe that.
