Monday, April 30, 2007

Classic isn't Adaptive. Adaptive isn't Agile.

In the world of software development there are many schools of thought on how to go about creating great software. Ignoring the creative side of things such as how you know if software is good, or what solution will meet what business need and so on. Even if you limit the discussion to how you go about implementing a solution once you have identified one, you will still find vastly differing opinions. We call these schools of thought methodologies because they define the method that you use to develop software.

Like all good architects, I too have a method to support my madness when implementing a new solution. My particular approach is thoroughly unique (just like everyone else I suppose ;-)

My particular brand of madness is considered relatively progressive borrowing heavily on the concepts espoused by Agile and Iterative approaches which are fundamentally Adaptive in nature.
The majority of men meet with failure because of their lack of persistence in creating new plans to take the place of those which fail.
--- Napoleon Hill
At the speed in which we are asked to deliver solutions, in an environment in which the business needs remain volatile and the resource allocation continues to be fluid, I feel the only responsible choice in methodology is one that has an adaptive component.

Are you still following a Classic approach? How's that working for you?

This past week I had great opportunities to talk with some charming gentlemen at Microsoft who are working on the next generation of Team Foundation Server and Visual Studio Team System. It was great to see them bringing more adaptive principles into the product. It bodes well for the future.

And for someone who is actively working to solve these challenges now instead of in the future it was very validating to see that our thoughts and approaches were similar. Very validating indeed.

Monday, April 16, 2007

Healing The Sick

The project I am working on would be classified as a Large project by most accepted industry standards. Because of its size, I find myself acutely aware of the differences between small team and large team development efforts. The things you care about and the inefficiencies you can afford are vastly different between these two types of efforts.

Lately, I got a chance to see the movie "The Pursuit of Happyness". In the movie the lead character is trying to become a stock broker and during his internship he has to perform cold-call sales. During one scene the narration explains that in the pursuit of success the character did things to improve his efficiency that others wouldn't. He wouldn't hang up the phone between calls so he could have more time calling. 8 minutes in a day. He wouldn't drink water so that he didn't have to use the restroom during the day. These are the types of things I really identified with.

Now of course, these are very extreme examples but the point is how little inefficiencies really add up. When you are a team of 10 everyone being 10% inefficient is really only about 1 additional body. On a short project you will likely be able to swallow that with some extra hours and extra effort by the existing team. When you have 100 people, the cascade effect from rework and lost time would magnify to a cost equivalent to more than 15 people! And this is even on a short project. As timelines get longer, the magnification is even more impactful.

In software development, optimism is a disease; feedback is the cure.
-- Kent Beck
The ways to counteract this impact from inefficiencies generally require more upfront work to codify engineering processes, checklists, review expectations, and so forth. You need to spend more time lay down the guidance on how the work will be delivered, how teams will get along, etc. When you laying out this guidance the processes will require more oversight, more documentation, and more tracking steps. It will generally require a much heavier footprint then equivalent processes used by smaller teams.

To put it another way, you will spend more time tracking what is being done because you simply must catch issues early and the cost to let things get off track is significantly higher.

Needless to say, I'm getting better at laying processes like that down in written form, but there is much more that could be done. Do you have experiences like this? I'd love to hear how you are handling this issue.