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.

Agile Adoption (the story so far)

We have been introducing Agile development techniques to our development group over teh last few months. This includes product management, business analysts, QA, and development members.

Adoption I believe has been slow but successful. The main reason for this has been that our existing waterfall-like process really wasn't that bad. We had over the years come up with good documentation that were an appropriate level of process and documentation to be meaningful. I think there is some don't-rock-the-boat mindset, but even those people have been more engaged in this than I would have ever imagined.

So if our process "worked", why even look at agile?

We needed to investigate agile because we needed to be agile. Being a hosted web application, we have chosen the model that we release "small and often". While the level of specification has always been good, our lack of software team management often meant that deadlines were missed or project size mis-estimated. We are looking to add SCRUM techniques and iterations (with deliverables at the end of each iteration) to serve as milestones along the way. We need the agility to deliver larger projects in iterations. We need agility to help us to be able to quickly deliver code if needed. We need to be able to iteratively deliver features, so that we can respond as a team better to changing priorities. Agile will give us that. We have been able to implement a few mid-sized features this way, and it has been successful.

So what have we done so far?

For a given feature, we enlist a feature team that includes product management, development, QA, DBAs who a business analyst "pitches" the feature to. We're assuming that at this point it has been determined that there is a business need for this feature. The feature team meets and fleshes out user stories. These stories are weighed as far as relative complexity, and are broken down into sub-stories until they represent some reasonable set of scope. From the stories, developers create tasks which are grandular enough to put meaningful estimates on.

User stories are also categorized on a MoSCoW scale, meaning Must/Should/Could/Won't. I.e. relative priority. We want to make sure we get all of our "musts" done for a release.

We haven't really calculated developer velocity yet on an individual basis. We are using generic "half day of effort" to be a story point. We hold developer stand up meetings daily, where we should be tracking progress in terms of completed story points which can be tracked on a burndown chart. We haven't implemented this yet.

We have looked at developing personas and are interested in this as a group. We just have not made the time yet to develop meaningful ones. Again, this is a mature web product where we are on fist name basis with some of our key clients. One of our product's strengths is our teams' ability to respond to user enhancement requests. Because we are already intimate with several of our customers, we have not dedicated the time to build personas that represent them. I still believe it is worthwhile because it removes some of the personality of the individuals that we know from the roles that individual plays. Personas don't have to be flat and dull, but they should also not instigate any bad feelings or other baggage around interactions with a specific client individual.

I am encouraged.

I think my organization has adopted well the agile principles we've put forward. We are still amatures and feeling our way through the landscape. Also, we've stopped pushing new agile concepts for the time being as we digest the basics and become more familiar and trusting of them.

Adding Agility to a mature Java product.

Having heard Dave Hussman give the lectures on Agility at the NFJF conference, my supervisor and I came back fired up to see how we could introduce it into our organization. I'm just now at the point where I can do some reading on the subject, and have a couple of resources that are a good read.

First, my supervisor handed me some printouts yesterday of a whitepaper entitled "Making Agility Stick", Cutter Benchmark Review, Vol 7, No. 7, July 2007. With that many sevens, how could it be bad? Actually, it's quite good. It has a contribution from N.C. State's own Laurie Williams, from the NCSU Laboratory fo Collaborative System Development, among others (but I have to hype the local talent!)

My point with this entry is to journal my experience introducing Agile into my organization. I'm a lead developer, so I have a peer relationship with my teammates - so I am really not at a position where I can mandate anything, I can only encourage. This is fine by me, it fits my leadership style.

As of today, I am not that familiar with agile development at all. I've experimented with XP in short bursts. My current officemate and I work well together in pair-programming situatiuons, but the activity is usually reserved for crisis emergency-fix situations. I know that the goal is smaller relases with rythm, incremental/iterative development that focuses on making progress "burning down" your stories in "sprints". Yep, that's all I know, and I don't know that I have even that correct. Laurie said in her article, "Agiliy is not an option - you just nee to determine how to go about being Agile." And with that, my study begins.

Agile is not a single methodology, but a category. The well known Agile methods are:

• Extereme Programming (XP)
• Crystal
• Feature Driven Development (FDD)
• Dynamic Systems Development Method (DSDM)
• Adaptive Software Development (ASD)
• Scrum

TODO: link those to synopses

My biggest suprise was not that there were multiple, but how little overlap there is among them.

Making Agility Stick

Having just read this whitepaper, I wanted to take down some impressions. I think these will be worthwhile to go back and review as we make progress. Here are some quotes from the articles that jumped out at me.

People involved in a change need to be able to answer the quesiton, "What's in it for me? (WIIFM). Within a single software organization, WIIFM is different for each role (tester, developer, architect, manager, director, CIO, etc), if not for each person. Depending on WIIFM, a person may initiate change or resist change." -Laurie Williams, Stickiness of Agility.

We need to find out what about Agile works for each role and make sure it is communicated clearly. Everyone needs to understand what their "win" is supposed to be, and then fire them up to deliver it.

Rather than the organization's goal being "Transition to Agile", you must set a concrete tangible busines goal. Position that goal to be most achievable through the use of Agile methods, shrouding the often-disdained software process transition with the emotion of striving for unexpected and unprecidented success. -Laurie Williams, Stickiness of Agility.

We don't currently have a big, high visibility feature that will unify across development. There are a few medium sized projects, so it would be interesting to see how can umbrella them ala Five Live. "Five Live" was a push where a company adopted an agressive goal where it probably couldn't be achieved without moving to an agile methodology.

I am a firm believer that the relentless focus on speed mitigates many of the risk sources of projects: scope creep, changing priorities, mounting technical and defect backlogs, lack of dedicated resources, and so on... The concept here is simple, the less you sign up to deliver in one release, the less there is that could go wrong.
-Sam Bayer, Seven Rules to Making Agility Stick

Agile touts the ability to deliver the right thing faster, and that quote sounds like a reasonable assertion to me. With all the focus on faster, as a developer (and probably QA would react similiarly) it sounds like it may begin to feel like a vicious-treadmill-of-death. What is built in (if anything) to help people not feel that way?

"Regardless of changing conditions throughout the project, the team would never be allowed to adjust it's initial estimates, which in reality become the defacto committments to the organization.

In my experience I guess the "allowed to" would manifest itself in that the developer felt like they couldn't take the time to stop what they are doing and totally re-estimate if necessary. First, it makes them feel like they look terrible. Second, most developers thing they are just another half-day from delivery all the time, so think that re-estimation would be pointless. Third, estimating software as a task is aweful, and is typically wrong anyway. It's hard to get over those feelings and do it.

Will Agile Stick?

How do we keep momentum in agile? I can already imagine people reverting to where they are comfortable. In our orgainization, that would be our current waterfall model. I think there is a bit of resistance to Agile because truly we have finally gotten the waterfall working relatively well, so I think there is perceived risk of fixing that whih isn't broken. I can understand that sentiment. We just have to communicate what they should expect to see as the ROI. You simply can't argue with ROI.

NFJS - No Fluff Just Stuff (Raleigh Marriott, July 2007)

All I can say is that if you feel like you've been out of the Java development mainstream too long doing tasks for the Man, then this is the event for you.

No Fluff, Just Stuff

I really can't express how much I appreciate the lectures from those involved. I especially appreciated Dave Hussman's lectures on Agile, and David Gearys lectures on JSF/Spring/Ajax, and GWT introduction. There were typically 5-6 lectures going on concurrently, so you couldn't see everything. You could get the slides and source code though.

This is exactly what I needed to jumpstart me again after a busy Summer where I had been head's down coding. I'll definately be there next year. See you there.

If you can't be there, I STRONGLY recommend buying the NFJS Anthology Volume II which is a compilation of several of the lectures. It is very broad, covering:

• New Stuff (GWT, Groovy, AJax techniques, REST)
• Testing (Unit tests, Capistrano, FIT/FITness, continuous integration)
• Agility

Great stuff.

SOA architecture, but just one endpoint please.

I mentioned earlier that I work with a healthcare software company. In any EDI project, there is usually a common protocol involved, in healthcare that protocol is either HL7 or X12. The easiest way to speak those languages is to rely on an EDI mapping tool or "interface engine" to be your middleware.

There are several vendors out there that would love to sell you an interface engine, for the price of a garage full of Ferrari's. You can control the price some by limiting the number of endpoints through which you can send data to your app.

So now I have a project where my P2P path between our engine and our app will be thorough a single endpoint. Yay. So I have to build a hereIsEverythingFigureItOut() web service, in order to minimize the number of endpoints that we have to pay for in this quarter.

What's a boy to do?

As an architect, I am still compelled to do the right thing and build a proper API as it truly should be and let this assinine single entry point talk to an adapter class which tickles that API.

Addendum 8/27
Boy was I whiny that day... Sheesh. Sorry about that. The truth is that we did bring in the Rhapsody interface engine, which in its latest release is quite slick. I haven't had any hands-on time with it yet, as our senior analyst is hogging it (truthfully, I've been far too busy). As far as this project, we ended up not going with web services at all, but rather continued on with our legacy framework for the time being. Since then, I've been turned onto RESTful web services, which I'll have to do a post about at some point.

Tragedy hit Virginia Tech today.

I sit at my keyboard in utter horror as this story unfolds. My prayers go out to all of the families involved. As an alumnus, you always want the best for you alma mater. I have no idea what this young man's situation is, but the thing that saddens me the most is that he though he had no alternatives.

My heart does swell with pride, in my watching of Hokie Nation banding together to support each other in a time when no one can make sense of the actions of that day.

Let's go Hokies!

HL7 v 3.0 is a little disappointing.

I was disheartened to come across this post which describes other's difficult user experiences with HL7 v. 3.0. For those who do not know, HL7 is a well known protocol that heathcare providers user to interchange data. Ansi X12 is often mentioned in the same breath as HL7, if you're familiar with that one.

Well, the great thing about HL7v3 was that it was going from a character delimited format to XML. That would open it up to all sorts of benefits, such as schema validation, and much better parsing ability.

The (hospital) marketplace has been slow to adopt HL7v3, but software vendors are supporting it. It will only be a matter of time before we have critical mass. I just hope that my experience is better than the one referenced here.

On a positive note, I did email hl7.org about the availability of the open source eclipse plug-ins that are being developed for HL7v3. I received a nice email back from Richard Kavanagh himself (the development manager) indicating that they can be found on the Eclipse OHF site. I continue to watch the OHF and IHE projects with great interest.