I recently spoke to Scott Ambler, Practice Leader Agile Development, Rational Software from IBM about the benefits of the agile development method.
Ambler broke myths about agile development by explaining how it's better than some of the more traditional methods out there, discussed the different methodologies available and gave advice on how to smoothly transition into agile.
Q. Why do you think agile is better than some of the more traditional methods out there?
Ambler: The major benefits come from a greater focus of quality, discipline, working closely with business stakeholders and on delivering working software on a regular basis. It's just best practices from the real world that we've adopted and we're actively trying to improve things. I think that's the difference between us and the traditional community.
What are some of the agile methodologies?
At the methodology level there are things like extreme programming (XP), scrum — a project management methodology, agile modeling — for modeling and documentation, the open enterprise process — a basic combination of the XP, scrum, agile modeling, rational unified process (RUP) which is more of a full development methodology and crystal clear, but not many organisations are doing that.
The agile method attracts a fair amount of criticism. Why is this the case?
The reason there is a lot of criticism is that a lot of people don't understand what's going on, they don't know what they're looking at. There's a lot of misinformation out there which gets repeated.
People really are threatened by this, because part of the agile message is that you have to produce, you have to add value in a visible and measurable way and a lot of people from the traditional world really don't add value and they know it.
We're often criticised for not writing documentation, which is completely false. How can you deliver a system and not have documentation? It's just crazy.
Those sorts of criticisms cater to the prejudice of the traditional community. It gives them the excuses they need not to change their ways.
You've mentioned that the success rate for distributed teams is lower. Why?
When you distribute a team you're introducing risk, you're introducing communication risk.
Since we can't do face to face we start loosing a lot of the social queues, like body movement and facial queues. It becomes harder and harder to figure out what people are communicating. Also the worst way to communicate is via documentation. That's basically one-way communication. You cant question, you can't explore.
What is the biggest challenge of agile?
I think the biggest challenge with agile is cultural differences. It's not really a technology issue or a domain issue. People have these excuses to not change, because change is hard.
It's not a technology thing, but it is a culture thing. You have to choose more discipline. One of the big cultural challenges in the traditional community is that they confuse bureaucracy with discipline. Bureaucracy is bureaucracy and discipline is discipline. Those are two different things and we need to get away from that. So if you've got this culture around this bureaucratic rigour, filling out forms and doing checklists, it's going to be hard to move towards something quality-focused, value-focused like agile.
What would be the best way to transition into agile?
A couple of things. First, minimally you should do some pilot projects. Just because this is working for a lot of other people doesn't mean its going to work for you. You really do need to get you feet wet.
Then after that, the challenge becomes [that] you've got to roll it out across the organisation. That's where things get harder. Now the entire organsiation needs change.
Can you talk about the testing process in agile?
A technique that gets talked about a lot is test driven development. In test driven development (TDD) you write enough code to fulfill that test. This is an incredibly good practice, but it requires significant discipline, it requires training and you have to be allowed to do it.
There is a lot more testing going on by agilists then by non-agilists. It's still not perfect, so we need to get better at that.
TDD is equivalent of testing against the specification. The assumption there is that your stakeholders are able to identify the requirements. We know that's a false assumption. They're not good at defining their requirements and it's just not human nature. As a result, TDD can only be as good as what you've been told to do.
You've got to counteract that risk and the way you do that is by having an independent test team running in parallel, that's doing more complicated forms of testing. They'd be doing security testing, performance testing, usability testing and exploratory testing.
Do you think agile requires more skill and experience?
It requires more discipline, almost always that translates into more skill and more experience, but I've seen some people that are fresh out of school that are very good at agile.
The real issue is do you want to be disciplined and do you want to build your skill set over time?