_

As the Agile Manifesto approaches its 10th anniversary, SD Times is speaking to several of its authors to discuss the gathering at Snowbird, what perspective they brought to the meeting, and what they might do differently. The 12 original authors will reunite at the Agile Alliance Conference this August in Salt Lake City.

In this installment, we speak to Martin Fowler, author, speaker and Chief Scientist for ThoughtWorks, a software delivery and consulting company.

SD Times: What was your reason for attending the first gathering at Snowbird?
Fowler: Primarily, [I attended Snowbird] to spend a couple of days hanging out with a bunch of interesting people. A few years previously I’d attended some similar gatherings called WOOD (Workshop on Object-Oriented Design), organized by Johns Hopkins. That’s where I’d first met various people such as Ward [Cunningham] and Kent [Beck].

I also had some hopes we’d gain some interesting ideas from sharing our similar ideas on software development. I’d tried to bring out some common elements when I wrote the original version of The New Methodology, and I was interested in seeing how more would develop.

What area of development had you been working on, and how did you see it meshing with the other efforts going on at that time? Are you still working to advance that specialty? Where is it at today?
I was, and am, primarily interested in software design (or what many refer to as ‘architecture’). I’d become convinced from my experiences working with Kent that highly iterative development was a much better way to plan and run projects, and I was interested in how that fit in with design (hence my article “Is Design Dead?”).

Today we’ve seen from our experiences at ThoughtWorks that an agile process coupled with this kind of continuous design works very well. It’s been effective for us on small projects, large projects (of a few hundred people), and in offshore development. But there is still much more to learn, so it’s a happily never-ending learning process for me.

Looking back, is there anything you would have included or struck from the manifesto knowing what you know now?
Well, there are lots of changes I would have made then. It wasn’t my document but a collaboration of 17 people with egos almost as big as mine.

I look at it as a historic statement, one that really helped turn the industry away from its view of what professional software development should look like. In that, it achieved much more than I would have imagined, and that is quite enough.

But I think it also provides a great starting point for understanding what the key to agile thinking is, what Jim Highsmith refers to as “Being Agile rather than Doing Agile.”

There’s always been talk of tweaking it to better express things. And people often snicker and say that as an unchanged document, it’s hardly agile itself. But that snickering misses the point; the whole philosophy of agile isn’t about interpreting some dusty document, but in making your own journey of discovery. The manifesto is a useful part of that journey, but in the end you have to think for yourself. (And, sadly, many people dislike that message.)

Where do you see agile development moving in the next five years?
The biggest element that I’ve been focusing on is Continuous Delivery. Making it so you’re always in a state where you can deploy your software is a big deal. It provides better visibility on progress, reduces deployment risk, and provides for better feedback. Doing this for large enterprises is tough, and my ThoughtWorks colleagues have done wonders to make this happen for many clients. Over the next few years we’ll be doing much of this, and I think it’ll make a big difference to how software fits in.

At the other end, there are growing signs of real traction with the user-experience community. Too many of our projects at ThoughtWorks start with us being given a detailed user-experience design done by some agency with no opportunity for feedback from architectural concerns or production experience. We’ve been gradually making progress at getting clients to roll the user-experience work into the agile process so you have a continuous design process both on the skin and the innards of the software.