| QUESTION & ANSWER |
Scott Ambler: Agile the leading approach for software development |
 |
By Jack Vaughan
05 Dec 2007 | SearchSoftwareQuality.com |
|
|
Agile preacher Scott Ambler says Agile software development has become mainstream. But while some groups think they're doing Agile development, they're really just hacking -- and "giving real disciplined developers a bad name." In this Q&A Ambler outlines four things a team should do in order to be considered Agile, and he talks about the impact Agile has had on large-scale projects.
How do you see Agile development or modeling today versus at the turn of the century ... back in 2000? Is it mainstream?
Scott Ambler: It's definitely on the upswing. We have seen positive growth throughout the industry for a few years now. In North America, it is being followed by a majority of organizations, according to the Agile Adoption survey done at Dr. Dobbs.
Yes, Agile is mainstream. I think you'd be hard-pressed these days to find anybody -- except for some folks in the data community -- still promoting the old ways of working. It is definitely the leading approach.
With Agile, people may say, 'Yes, I do it,' but it becomes a question of what they are saying 'yes' to -- what they mean by 'Agile.'
Ambler: That actually might be one of the great challenges now for the Agile community. I would argue that they need to step up and define 'Agile' a bit better. A lot of people point to the Values Statements and the Principles, which are very good things, but they are not necessarily criteria for determining whether or not you are Agile.
|
|
|
|
|
The reason why changes in requirements are actually a good thing is that you want to build software that meets the needs of your stake holders.
Scott Ambler
Practice Leader Agile Development, IBM
|
|
|
|
|
|
|
|
|
|
What I am seeing is a lot of people who are basically doing ad hoc development -- hacking-type stuff. And they are claiming to be Agile because, for example, they are not doing documentation. Well, the fact is, no, they're hacking, and giving the real disciplined developers a bad name.
I have four questions I ask to determine if a team is really Agile.
The first thing I ask is 'show me your unit tests.' As far as I'm concerned, if you are not doing unit testing in a regression manner, you are not Agile.
The second thing I ask is 'introduce me to your stakeholders. Show me some evidence you are interacting with them on a daily basis or at least several times a week.' I see a lot of people with excuses. I've seen a lot of people give up on that.
The third thing I look for is evidence you are producing working software on a regular basis. I ask you to show me the working software you have right now. Show me the CM [configuration management] [versioning]. And show me that I can talk to somebody who is not on the team, someone who has seen your working software week by week.
And the fourth thing I look for is evidence you are doing self-organization, so that the team is in control of its own destiny. There are constraints, obviously, but the team should be calling the shots on the important things.
If you miss any one of those criteria, more than likely you are not Agile.
Agile processes, and extreme programming before that, seemed initially to be meant for small teams. What do you see as the impact these days of Agile development on large-scale projects? Much of the early discussion was about co-located teams.
Ambler: This is one of the things we surveyed too. People are in fact doing Agile on large-scale efforts. There are projects with hundreds of people now. Actually, within IBM, the Lotus Sametime development team was over 200 people, and they followed an Agile software development process. The Eclipse team is following an Agile process that is called the Eclipse Way. They comprise hundreds of people worldwide working for different companies, so they are in a reasonably complex situation.
Didn't some of the early manifestos imply people had to be in the same place to work together successfully?
Ambler: Yes. There are definitely leanings toward [co-location] in the Agile community. I think one of the challenges that the Agile community currently struggles with is they are sort of victims of their own rhetoric. At the end of the day, they struggle sometimes to communicate what it is they actually do.
For example, there are a lot of people that push for co-located teams, and rightfully so. That is definitely a very good strategy to do. But that is not a requirement for being Agile. One of the things we looked into in the Agile Adoption survey was how people are doing non-co-located development. They are struggling a bit, but they are still succeeding at it.
Once you get into any reasonably complex situation, your team is going to be distributed.
So much of this is about people, and rightly so, but what about tools? Are tools enabling Agile?
Ambler: There is a heck of a lot of tool development going on within the Agile community. People are building tools such as Fit and Fitnesse to do testing, the XUnit suite for testing, Cruise Control and BuildForge for doing Continuous Integration -- they are really rethinking the tooling. Jazz from IBM Rational is built for non-co-located Agile development to help you communicate and share information when you are not in the same room and maybe not even in the same time zone. That is in beta right now, and people can go play with that if they want.
Some of us feel that scope creep is bad. Yet, the last time we saw you, you more or less said, 'If you don't have scope creep, you are not being Agile.' Are requirements in Agile development really different?
Ambler: This is huge cultural issue. We've been told for decades that scope creep and changing requirements is a bad idea. That is completely false. It was an interesting theory, but it was fundamentally wrong. The reason why changes in requirements are actually a good thing is that you want to build software that meets the needs of your stake holders, and people are not good at defining upfront what they want. In Agile, we travel lighter, and change is not the enemy. People are not interested in having software that is built to spec; they'd rather have software that meets their actual needs.
Scott Ambler is one of the individuals closely associated with the Agile methods movement from just about the get-go. He joined IBM about a year ago and has been preaching the Agile gospel within the company, with customers and at public forums. He continues as a contributing editor to Dr. Dobb's Journal.
|
|
|
|
