Deven Kalra’s Weblog

Agile in a distributed environment

I had spent 4 years at my last job at VeriSign and the urge to do another startup started to gather steam. I left VeriSign in November 2006 and decided to strike out on my own. This time though, I decided to take a different tack.

In my previous two startups, I had raised millions of dollars in venture money and taken the conventional route of building a company. I started my first company, Adaptive Media, in 1996 and my second company, Langoo.com in 2000. The computing environment, the development tools, and the availability of global development talent has changed considerably since then. My gut feeling, when I was thinking of my third company, was that the cost of development for most web-based applications is now significantly lower and one can make a lot more progress with limited capital. I decided to test this hypothesis by self-funding some ideas of my own. I registered a domain name (infodoro.com) and made the plunge.

While at VeriSign, I also got quite interested and gained experience in the Agile methodology for software development. VeriSign, being a 10 year old company, already had a number of processes and tools in place. Based on the different trainings on Agile methodologies as well as internal reasons, the focus of Agile at VeriSign at the outset was on the daily scrum, creating backlog and tracking the backlog (in that order).

When I started to develop software for my new company (infodoro.com), I started to work with a distributed team in eastern Europe and India and the daily scrum was not as practical. During that time, I realized that Agile is a lot more than the daily scrum. And it is quite practical and effective to do Agile development in the true sense.

Agile development is really about iterative and incremental development (IID). And, it is about avoiding surprises. And, it is incorporating change continuously into the development process and in to the code. Towards that, from almost the beginning we made sure that we had

1. A central globally available source control system
2. A globally available bug tracking system
3. A globally available test case management system
4. Insistence on writing unit tests
5. An automated test suite and harness
6. A continuous code integration system with the unit tests and the automated test suite integrated in
7. A globally available wiki, task management and messaging system

And we were able to do all of the above with just a few hundred dollars of infrastructure cost by leveraging open source where we could. I will write separately about the tools we used and the setup we created.

We still have daily meeting with one team (India). We have frequent communication with the developers in eastern Europe.

The results of this upfront work have been very encouraging with the quality of code produced and the quick turn around on features.