Sun - November 23, 2003

What is Agile anyhow?



Yesterday, my friend Vlad and I were slowly wandering through an outdoor art show in Pasadena. He asked me to give him the defining characteristic of Agile development. He has only experienced agility at a shop practicing XP.

Clearly the methods all share a common vision, declared in the Agile Manifesto. Vlad was asking for something more tangible.

All those agile methods: RAD, Scrum, FDD, XP... they certainly must have a common characteristic. What might it be? Or is there one? Take a moment and consider your answer.

The methods address different issues covering a wide range of topics - risk management to planning to management to individual practices - perhaps it is unreasonable to ask what they have in common.

When I visit a shop practicing agility, I feel different. There is a buzzing; a kind of intentional focus that is very clear to me. The people involved tell me that it feels different to them as well. A gut response - but hardly a defining characteristic.

My answer blurted out to Vlad. "Why, it is the taking of small steps." Today I can still stand by that answer. It certainly is a paradox. To be more agile you must take smaller steps. A feature at a time, a test at a time, a short meeting every day.

It appears obvious when you think about it. If I do rock climbing, I better take small steps. The lunge is dangerous and counter productive. Moving one hand or foot at a time works a lot better. The marshall artist moves in such a way to always remain in balance. She does so in small movements.

Perhaps it is enough to remember the child who learns to walk one step at a time. We all did it once.

Posted at 07:11 AM     Read More  


Fri - November 21, 2003

For once I am saving



Keeping up on the latest hardware has been a state of life for me for some time. Basically since my first - a Mac SE that went with me on business trips.

Things have slowed down now and I have gone from 5 machines at home to one for me and one for Corry. My iBook seemed just fine for Webbing and Emailing and a bit of writing.

Ah, the development bug has struck again. I want to explore Eclipse and open source. The iBook does the work but it really thinks about everything.

And then, boom. A big G4 tower with lots of hard drive and RAM just appeared for a mere $500. For once I am getting the deal rather than giving it to others.

It has Jaguar on it and dual boots to OS-9. I think a brain wipe with a clean Panther install with just do fine. It certainly will let the G4 scream.

I'll let you know how Eclipse does on it.

Posted at 09:29 AM     Read More  


Wed - November 19, 2003

It's 45% done.



At the AYE conference, mentioned below, I co-hosted a session on software project measurement. We had a simulation that gave an opportunity for the participants to explore measuring and the impact it has on development. The difficulties of obtaining good metrics and the what they might mean or not mean about project completion were exposed.

After I returned home I had a chance to read Jerry Weinberg's article Destroying Communication and Control in Software Development in the April 2003 issue of Crosstalk, The Journal of Defense Software Engineering. It is an informative article that illustrates some of the many ways that we fool ourselves about project progress.

One item that I noticed was in a section titled: Project Management Reviews. In this section Jerry suggests that the presentation of project status data that is not based on actual work is a common way we inhibit good communication. Specifically he says, "Above all, monitor and compare predicted and actual accomplishments, where accomplishments are strictly tested/reviewed work products and not abstractions such as 45 percent complete, and are not chunks too huge to see work products from one review the next." The italics are his.

What struck me was the use of the word abstraction. 45% complete is an abstraction? What a perfect way to describe what happens.

Imagine the following sequence: 'Hum. The schedule is 20 person/days. We just completed the ninth day. Things are going well. I think I will put into my status report that we are 45% complete.'

Sound silly? Not really. About two years ago, I heard this sequence (the number are slightly different) from a project manager of an Agile project. It is hard for me to count all the times that I have seen status reports that contained such abstractions. I have written them myself!

In the simulation at AYE, the developers managed to deliver within the target schedule after a 100% schedule slippage. After the simulation, the developers discussed how luck played a huge role in their delivery success. If one specific event had not occurred in a timely manner, delivery would have been late.

Agile practitioners cite the need for honest and frequent communications. I suggest that the honest and frequent communication of abstractions does not help. The data that we present should be based on real accomplishments. And we should always remember that Lady Luck watches over our shoulders every day.

Posted at 08:03 AM     Read More  


Fri - November 14, 2003

India strikes again



This blog is created by iBlog which is sold by Lifli Software, a firm in India. Their product is very fine and their email support has been to the point and clear.

Recently I was at OOPSLA 2003 in Anaheim and talked to an old friend who has been looking for work for some three years. He was lamenting about the movement of jobs to firms outside the USA. While I understand his frustration at a personal level, it is pretty clear to me that the trend will continue.

What software will stay locally produced? Not much I am afraid. The leveling of wages we have seen in manufacturing will occur in software. And more rapidly since the movement of IP required to make software can happen much more rapidly that manufacturing methods.

Leading edge development will continue here but less and less as time goes on. One off software, software that is very tailored to a specific local task, will also continue to be locally produced since the IP transfer cost can not be spread out. Once the American monopoly on the desktop is broken, just a matter of time, the business models that have driven the software explosion will no long work as reliably.

So how can Agility help with all this? It appears that the most agile teams are when the customer and the developers are co-located. Perhaps if the competitive pressures are very intense the increased productivity of co-located agile teams will keep work in the US. I would suggest that you do not hold your breath.


Posted at 02:45 PM     Read More  

©