Working with Offshore

The increased efficiency of the online communications tools, offshore software development has become more prominent in the IT industry. Currently I am working with a bright off-shore development team located eight time zones away. There are some challenges, but overall things are moving well. In this blog, I would like to share my experiences and give a few tips, if I may.

Communication

Obviously not everyone speaks, writes and reads English as their first language. English is also my second language, but living in the States for over fifteen years, I seem to do well and even blog about it. Specifically with software development, getting one's point across is very essential when the team is not co-located. We use a few online, instant messaging and audio/video programs. Earlier we tried ooVoo, however the off-shore team found that it was CPU intensive (with all the ads and everything on the side which I am not too surprised), and they suggested we use Skype. So we switched. It works pretty well and adds to our daily email exchanges. Definitely pick an instant online communication tool which all the team uses

Within the team, our direct point of contact speaks the best English as expected, yet others are good in writing. There was one time that I called one of the developers and could not understand what he was saying, and he probably did not understand what I was saying either because he requested that I speak slowly. And yes, I could speak quite fast at times. Then I quickly switched to instant messaging. This allowed my offshore developer to think more over the text he reads, then respond. I don't plan on calling him directly anymore. Although a conversation is good thing, but it feels odd when the other party is not sure what is being said. Video definitely helps with sending the gestures and such. But in general it is good to keep things in writing.

Get to know your team

Haven't got the chance to meet the team in person, but initially I mentioned that I was going to visit their country and asked and requested for certain information. They were quite excited and eager to share the info and their culture. I inquired from one of the developers about his beer tastes and whether he drank it or not. Again myself being from overseas, which is not too far off from this location, exchanged a few other stories and got a little more personal. I think this really helps in creating a more friendly and understanding atmosphere.

Don't be a dictator

One of the lessons, no matter how smart you are (or think you are), hopefully learned is to cultivate a shared development environment. Recently the off-shore team went ahead without checking with us and completed major refactoring. That caught me off-guard, but there is a lesson in that. First, the project needed refactoring and I was reluctant to do that right away due to another pending major integration (back-end) process. But that was all right. We regrouped and just this morning we had a teleconference call and discussed our refactoring process where I think everyone got on the same page. I did answer a few follow-up clarification questions but everyone is on the same page.

Let them have time to ramp up and study

In this project we are using ASP.NET MVC framework. Early in the project, one of the developers decided to take the M (Model) from MVC of the web project into an outside class library project. After checking and figuring out the reasoning, we found out that it was not such a good idea since ASP.NET MVC dictates convention over configuration. Yet the idea is to let the team find out and try to improve the code through refactoring and remodeling. My advice to team was, okay, there is another way of doing, but prove that why that way is better and if it makes the most sense.

Respect gets respect
This goes without saying, but it is better to state it anyway. Just because you are supervising, there is no point in being arrogant or bullish when discussing issues with the team. Everyone has opinion and when time comes, it is best to discuss. Try to understand where the team is coming from and give them respect for their idea and creativity. There is always more than one of peeling the cat ;-)

Try to stay ahead of them

Okay, this is my current challenge right now. We added two additional developers and it is getting harder for me to stay ahead, but I will keep reviewing the code base and provide feedback as it fits. I also have the other integration project which is ramping up as well. Anyway that is what I got to do. But the point is, it is important to stay ahead of them and give them direction and try to anticipate the changes in business and requirements. The one thing that is certain is things are going to change. Be responsive and reactive to changes, hopefully proactive more.

There will be many more tasks for us to do in this project. We have an agressive timeline, but using agile methodologies, specifically Scrum really fitst the model. We modified the process a little to meet our needs but it is going through. Our business analysts are creating documentation everyday which the development team is consuming. The TDD approach is really getting up there. Just today we got notification that our initial code coverage setups and implementation are taking place. These are great signs of progress and will hopefully allow us to deliver this product on time and within budget. I am stoked to work with these bright guys and I am glad to mentor and learn from them as project moves forward. But understanding each others' culture, either onshore or offshore and working on the communication skills are essential to what we do which is creating functioning software applications for healthcare business.

References:

10 secrets of successful offshore developmen parts 1 & 2

25 Rock Solid Tips to Supervise Offshore Development

It Depends...

Wonder how many times you heard this as an answer to a specific question by an expert of the matter. Scratched your head about what it means and question their authority. Yes?And it is true in many respects too given the choices we have around our technologies. That is a good thing, right? Well, guess what... it depends...

Recently I have been tasked with creating a technical specification document for a given application module. I delivered the document knowing what I know at the time and tried to avoid Big Design Up Front (BDUF) anti-pattern. I have to admit there are quite a few holes in my document but my goal is to fill up them as I find more about the requirements and increase my understanding of the application. So far we have is a few screens of wire-frames, an initial functional specification document. The business analysts are hard at work in peeling those requirements and creating/modifying the functional specifications. It's all good in the end as long as we have a grasp on the amount of the documentation. And, yes, we are using an agile methodology and have daily scrum meetings and two week Sprints. We are staying focused.

Including myself, the team is very new to this company. What are some of the challenges? Well, lack of requirements one might say, but I am yet to be on a project where this isn't the case. The second that you think you nailed down the requirements, guess what happens. It changes! Head First Object Oriented Analysis and Design book had a good chapter for this, “You're perfect. Now change!” Exactly. So I am not too hung on this. Just get me enough to start coding...

There is some worry about the business process, and lack of decisions. We are also going to use an off-shore team as well to do some of the development and testing. I expect to be working closely with this team at some level. I have a few questions and concerns with that, but I will bring it as it moves forward. Keeping development cycles short, feed-back loops tight and close. Wire-frame developers griped a little about not seeing the whole picture, but sometimes you don't need to.

As far as technologies go, I am all about .NET development which is our platform. This is a web-based application with multiple tiers, heavy emphasis on separation of concerns, testable, decoupled layers. There will be WCF services used by the business tier as well as third parties. I am pushing ahead with ASP.NET MVC framework with business objects (logic) in the middle, and ADO.NET Entity Framework in the data access layer. We are going to use Test Driven Development, writing our tests first, thinking “unit testing”. I realize that TDD is not unit-testing, but I am already spreading the words/ideas about the functionalities to test. I really believe this will help us increasing our code-coverage numbers as well as CCHIT requirements fulfilled. My goal is when some one asks me how this works, I could just run a few unit/integration tests and show that they meet the requirements. Yes, got to have tests... there is no other way around that!

Meantime I plan to write quite a few throw-away proof of concept code to aid the actual coding. I plan to address the cross-cutting concerns, exception management, authorization, authentication, logging, caching (defer it until I have more hands on with application), encryption and security.

Our database is SQL Server with some interfaces to legacy DB2 databases, We do have an aggressive time-line, as with most development teams. We are definitely going to be busy. Well, if you are going to ask me how is it going? You will know my answer...

Happy Coding!