Agile programming, god or bad

I was having an interesting discussion with my colleague, Ismael, today about Agile programming. I was arguing the benefits of Agile, and the use of stand ups in the morning, allowing to bring a team together and quickly review the project progress.

Ismael agreed in principle but felt this rigidity of standups was against the whole principle of Agile... and he cited one interesting blog from Steve Yegge

Steve's definitely loving his job a Google!!! I love it I agree there is a lot to learn from Google's way of doing things, just like there is a lot to learn from Academia or the way startups work.

In my previous company, I remember when engineering started to introduce agile programming very much like google's way. The first thing they said to the business is: "forget being rigid about a delivery date. We will launch whenever we are ready to launch".

OMG, be assure a lot of adjustments had to take place. This wasn't well received because it felt that engineering wasn't tuned to the need of the company.

One specific area that was highly dependant on launch date was the launch plan and all the activities around it (training, marketing activities, enablement of partners, trade shows, press releases, analyst briefings, etc).

These activities take up to 2 - 3 months to execute. So the business needs to know in advance when the release date is, so that they can best invest their precious marketing $ to maximize the buzz in the market and attract the most new potential customers.

Clearly Google doesn't have that pb, nor does academia or pre-customer startups.

As Keith puts it in his comment to Steve's blog:

"Yep, and why is that? It's because most of us in our industry are writing sotware for paying customers (who might happen to share an employer with us) who have a "soft real time" idea of the value of the features we build: ie, the value of the features is at a maximum at some time t and declines, perhaps rapidly, after that. These three kinds of development are all quite unlike this.

Google's products and services seem mostly to exist for the purpose of making online advertising through Google more attractive, and that's a continuous process.

My client's projects generally exist to make some business process 1) possible, 2) faster, 3) higher quality before the competition do that. The business sponsors of these projects want to know when the benefit is going to start acruing. So they need schedules. Rightly or wrongly, that's what they need. And that's why (in contrast to the named methods that camed before) the Agile methods tend to put an emphasis on early delivery of business value, and hence the focus on schedule. In XP, though, note that we would rather reduce scope that slip a delivery. "

This said, at my previous company, the business has learned to be more flexible about release date and engineering more accountable about their progress toward a set goal and more transparent about the planned released date. All in all, best of 2 worlds.

I am now looking forward to leverage even more this approach with LikeCube.