How sending my job to India saved my job.

This past Summer, I had the opportunity to travel to India. Here is some quick background on how exactly that happened.

On January 2, 2008, I came to work to be greeted with a departmental meeting. Turned out that my company's corporate office had just purchased my product's biggest competitor. Their product had a benifit over ours in that they had a post-acute module for providers that spins off a very healthy amount of $cash$ for the company. No reason to keep 2 versions of the same product, so they decided to retire our product (though some active development continues).

The plan was to go hire a bunch of indian developers in Bangalore to maintain my product, while us developers moved onto the newly acquired product. I was chosen to get my passport/shots together and it didn't seem like long before I was on a plane for 26 hours from RDU to London to Bangalore.

Creating the team

Prior to arriving, we phone screened dozens of candidates. We worked with a contracting house to arrange interviews which I conducted over a desktop sharing tool called Microsoft SharedView.

The interview was challenging, sit down, open eclipse, write an app according to a spec that I give you. We sit there and watch their every keystroke. Once guy caved in and gave up under the pressure - he refused to continue! We got ourselves down to a shortlist of about 7 developers. We decided among ourselves down to 5, which is how many spots we had to fill. We made offers to 4 of them. All 4 accepted.

But will they all show up?

Plans were made that I'd travel to India to provide some on site training on our source code, development process and source control, development patterns, etc. When I arrived in India, for the first day I was totally sick. I got to stay in the corp apartments on Airport Rd in Bangalore and recover while I watched IPL Cricket. Barbara and Becky did introductions and the first training day was pretty light. The amazing thing was that the 4 developers and 2 QA all showed up to work.

I talked with Umesh, the CEO of the resource provider, and he said in this market competiton it was very common for developers to interview, be given an offer, accept - but never show up for work on the first day. The will take another job. Everyone was eager to take this job. Apparently, this happened because of 2 things. The candidates respected us because our interview was hard and our standards were high. Second, they respected that we treated them with respect - and talked with them as collegues. I can't emphasize these two points enough regarding successful interviewing in India.

The cast:

Angles. He is very quiet. Still waters run deep with this one. He's probably the most experienced of the bunch. Angles has a booming deep voice - even though his English is very good, his deep voice makes him hard to understand on a speaker phone.

Vinod. Vinod is a good guy. He is eager and appreciative when learning new things. He's not just trying to pad his resume with abbreviations. He takes pride in his work.

DeepaJ. She also is an excellent developer. She is not afraid to get into the code to learn how something works. The other developers tease her a bit because "the red comes when she talks to David" - she blushes :) It is certainly doesn't hurt my feelings at all.

Kalyan. Kalyan is also great. He has a good understanding of how things work, and picked up things very quickly in our training. He works hard helping us in the reporting area after we lost Philip and Nathan. The best thing about Kalyan is that he looks like he is smiling even when he isn't. He admits it gets him into trouble.

Visa & Ishita. These 2 gals are our QA contingent. Visa is a firecracker. Ishita is very determined. Just this week I was explaining how something worked, and Ishita hung in there and challenged me on it. I can appreciate that.

We are fortunate to have each one of them!

I got lucky on the last day

On the very last day, I hired our Java team lead. I really got a good one. He is cut from mentor cloth. He wants to "own" the team, but he wants to grow them. He wants them all to succeed. I'm fortunate to have someone with good character in this position.

Training

Training was pretty straightforward. They all got it. I couldn't believe how quick they took it all in. I had always been told that in Indian culture you have to be careful that they will claim to have understood something that they don't understand. They REALLY don't want to disappoint. We've seen this over and over again in a good way - in that they do not want to miss deadlines. They are happy to work all sorts of hours provided you simply appreciate it.

How are they working out?

Now we're a few months into using the team. We have a status call every day and go over what they are to be working on, and what they accomplished. We do this at 8:30 EST, which is 7PM Bangalore time. It takes about 30 minutes out over every day. It's a status call as well as a social outlet. We want them to continue to feel like part of the team. As of right now they are slightly ahead of schedule on our next release, so we'll be able to address a few additional things at the end extra.

But how did it save my job?

Going into the trip, I wanted to quit - I really wanted to quit.  But I really like this team we've assembled.  Not even the team, but every individual on it.  I wish them all the success in the world.

Getting caught up - how did the "agile experiment" work out?

For a while, blogging was a craze. Blogs are hard to keep up with, but at this point it's important at least for me to journal what goes on. So much has changed in the last year, I don't know where to begin - so I'll just try to pick up where I left off. A flury of posts to follow.

As a team we've morphed our processes to something that resembles Agile/scrum. Changing development processes is so disruptive, because it really takes a lot for your entire expanded team to get on board. There was a lot of interest, and (almost) everyone on the team was a willing participant.

It was tough not having an experienced "coach"/"scrum master" on board. We (Simon King and I) relied heavily on what we took away from David Hussman's lectures from NFJS. I got some real help in the form of our QA Lead later in the year, when she was able to attend Agile (?) in Washington D.C. She and another QA analyst came back renewed, at a time when I was "hitting the wall" and getting tired of carrying that particular ball. She has introduced at agile management tool, VersionOne, which I'm sure I'll touch on later.

In the meantime, Simon, who was my development manager - got promoted! For a while we were marching along, but running out of gas.

I have to hand it to Barbara though. Of all the people I really expected to let it regress to what we were doing before - she stuck to it, and continues to stick to agile. 

Again, we had a fairly lightweight waterfall-like process that worked pretty well, so it's not like people were going after our process with torches and pitchforks... Moving to agile was a huge business risk because we were moving to a process we had zero experience with.  Barbara's been a tremendous help to me, helping me transition from a development role to more of a development manager role. On top of all of that, she's a good friend. Her advice means more to me than anyone else at the office.

Have we gotten better at agile?

We have become more confident in agile. I'm not talking about in the sense of reaping all of the benefits that agile has to offer a development group. I simple mean with respect to the mechanics of carrying out the process. I'm pleased that it lived this long.

So How Do We Do Agile?

We are sizing User Stories with story points (out story points are $ amounts). We do release planning based on an overall dollar amount of work we expect to get done. A $1 amount represents about a man-week for us, based on what a Sr. Developer expects that a moderately experienced developer could get done in a week. We then estimate features by giving them a $ amount of $1-$10, and then pack a release full of features in priority order. We're always working on the highest priority item throughout the release.

Next, we break out the release into some number of iterations - typically 8 2-week iterations, plus some extra time at the end for QA integration testing. I'll assign the features to iterations, and then develoment resources to particular features during the iteration. I like to have pair-programming so we have 2 people responsible for any particular part. It tends to keep the ball moving down the field.

Each feature is broken out into User Stories, each given a MoSCoW rating of priority. Each story is given tasks that it will take to complete them. Our latest accomplishment is bundling of Stories and Tasks together into what we are calling "testable units". Once a developer has something build-worthy, we let QA know and they cut a new software build from whatever source countrol branch the feature is developed on. This is working particularly well, helping solve the issue of QA getting jammed for time at the end of a release. In order to support this though, we've gone to a more agressive branching strategy, making more feature branches - merging down to the trunk when we commit to shipping them (fixing any defects found at that point directly in the trunk, as the feature branch is closed).

Hmmm what else... Well, there are things we are doing that are NOT agile. I'll cover those in another post.