How do you see Agile development or modeling today versus at the turn of the century ... back in 2000? Is it mainstream?
It's definitely on the upswing. We have seen positive growth throughout the
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
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.'
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.
|  | ||||||||||||||||
| |||||||||||||||||
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.
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?
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?
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?
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.