Agile is undoubtedly a proven method for development. But does it work in the services fields, especially for distributed teams around the world?

The South Beach Diet

Vijay Vijayasankar is an associate partner with IBM.  He manages hundreds of people who do services projects for a number of multi-billion dollar companies. I sat down with him for a conversation last week. He told me about a post he wrote last year that compared Agile to the South Beach Diet. He tried Agile. He tried the South Beach diet. He drew these conclusions.

Like weight loss, there is no magic bullet for software development.  To lose weight, you have to eat less, improve nutrition and exercise. A South Beach Diet may work for some but it did not for Vijayasankar. He made this comparison to Agile:

In parallel, I was going through a similar excercise at work – trying to find an optimum way of managing the projects I get to run. I have read and tried several different things over the years in a variety of projects. Over the last couple of years, I have been fascinated with Agile development and hence I have been reading, talking to others, and trying it out in teams I manage – and again, I have  come to the firm conclusion that, just like the various dieting schemes – Agile also does not work for me.

He compares Agile to building a deck. It’s like hiring someone to come over, review the work as it proceeds with no plans for what it will look like when done. Part of it gets built, you take a look and start again until completion. You pay as you go. In services projects, customers want a clear idea when the project will get done and what it will cost. That’s an issue with Agile.

Global Teams and Agile are like Oil and Water

Agile processes do not work with distributed teams. The process require daily meetings, conference calls.  This gets tough when the team is in India, Europe and Asia.

The Superstar Issue

The mindset is different in a project group. It’s not just superstars. People of various skill levels and talents make up the teams. In such a group, not everyone can go off with minimal instructions and get the work done for the next day. Some would argue that the superstars can be the ones who get the work done and the others will not be needed. But for large projects, you need a larger team. The superstar can’t work 24 hours a day, seven days a week.

The Reality

A project does not have to be based entirely on an Agile model. Nor does a Waterfall methodology need to be pure in its own form. It can have elements of Agile. Vijayasankar says Waterfall processes often have several points in the process where evaluations are made, similar to how Agile projects proceed.

I am not an extremist when I think of methodologies.  In my opinion, Agile is going through a hype cycle exactly like how it happened with SOA.  Once the hype died down a little, we mostly figured out what is possible with SOA and what is not. SOA is great for several use cases, and terrible for others. Same is the deal with Agile.  Just because Agile possibly has the issues I called out above, it should not be inferred that Agile should not be used. If you have a bunch of highly skilled people, where the team has a clear vision of the end product, and/or where time to market is not such a big deal – all these challenges will vanish. Such a team can probably come out with a great solution using Agile. But in the type of projects I am dealing with – I don’t think Agile can succeed.

But what do you think? Is Agile better or worse for services projects?