Posts Tagged ‘remote software development’

6
JUN
2012

How Communication Eliminates Nightmares During Software Development Projects

Comments (0)

Entrusting the development of a web-based application to a software services company, with their programmers located outside your home country, can be a fearful proposition. The application needs to be right, the code needs to be flawless, and the vision for the final product needs to be executed properly. But equally important is the provider’s ability to keep the client comfortable and confident throughout the development process. This is achieved through making communication and responsiveness a top priority.

Communication should begin from the very first contact with the company. Do they return a sales call? If not, that should raise a red flag. If the company doesn’t respond to a client when they are seeking service, there can be little confidence that the company will respond to questions or ideas about the product they are developing.

The goal of communication for a software services provider is to make the client feel like a partner in the process. It should eliminate the guesswork and focus on what the final product will look like and how it will function. In some instances, a vendor relationship, where the client asks for something and the product is simply delivered, may be all a client needs. But when a new and unique application is required, the client needs to feel invested in the development process, and they need to feel like a partner in that process.

When a client pays for the expertise of software developers, they want to have input into the process. They need their provider to be responsive and to tell them when ideas don’t make sense or when there is a better solution to a problem. The goal of the services provider should be to make development a collaborative process with the client and allow for fine-tuning throughout development. This sort of constant interaction ensures that there are no surprises when the final product is delivered.

Softjourn approaches communication with its clients with unconditional responsiveness. Phone calls and emails are always acknowledged and returned. Softjourn prides itself on making the customer feel important in the development process, because they are. The client is the person or company that has the vision about what they want from the project and it takes constant communication to fully grasp the goals they have for their tools and software. Ultimately, the better the communication and responsiveness, the better the final product will be.

There is little debate that remote software development is a viable and cost-effective way to get development work done. Typically, hiring equivalent talent and expertise in-house can be expensive and superfluous. But the provider should provide more than mere execution; they need to communicate and collaborate with the client to make the best of everyone’s expertise: the developers’ expertise in creating applications and the client’s expertise about the tools they need for their business.

Categories: Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams |

19
FEB
2012

What are start-ups asking…..

Comments (0)

I had written before that most start-ups are expected now to work with remote development teams in order to lower their burn rate.   But what about those other start-ups?  The ones that are six, seven or more years old and still call themselves a start-up.  In part they are doing this to set and continue a certain mindset; we move fast, we’re lean, not a lot of bureaucracy to get things done, etc.  So what about this type of start-up, what are they interested in?  As often as not they may keep everything in-house, thinking they move too fast to work with remote developers. They may have tried outsourcing (either onshore or offshore), but it failed. Sometimes I am hearing that they tried it 3, 4 or more times and every time it has failed. But they are still interested to try it again.  Can give them credit for wanting to try it again, but it is interesting to dig in to the reasons they give for the failures, in order to determine what not to do next time. Let’s examine a common reason given for failure and see what a start-up of this type can do to avoid this issue in the future.

One reason I have heard for why outsourcing has failed is “bad code”.  Now I can see that you do not want, and should never settle for “bad code”. As a customer, you should never settle for code that cannot later be easily maintained, that is not architected correctly, etc.  Also, of course you have a right to look at the code while it is being developed; it is your code that you are paying for. Certainly that should never be an issue. Often, however, when I ask exactly what was so bad about the code, “Why was it bad?”, the answers sometimes become a bit vague… I would expect to get answers which were more concrete, something like, “They wrote the app so that the entire survey was loaded in to memory, therefore the app could not easily be run on different telephones which had less memory.”, or something similar depending on the platform or the type of application in question. Or to hear a reason such as, “The developer did not document the code correctly, or at all.”

However, a more typical answer I hear is that it was just bad code (not from everyone of course, but often enough). Here in lies the problem I believe and I think you can see it too.  If you can’t define exactly what you didn’t like about it or what was not done correctly, then how would the developer know exactly what you wanted.  You may argue that you should not have to tell the developer to use common acceptable standards for the language they are developing in, or to comment their code, etc., with that I would definitely agree with you.  But if that were really the problem, then that is what I would hear from VP’s engineering or CEO’s of companies as the reason why outsourcing did not work for them in the past.  But I do not hear that, I just hear, “the code was bad”, which leads me to believe there is something else behind why it was bad.

So how do you get around this the next time you want to work with remote developers? There should definitely be a discussion of what you expect in the code, with the developers.  Telling them you are going to be looking at the code is one thing, well they should expect that you will look at it since it is your code and it will be delivered to you. But being more concrete as to what you expect as far as:  official coding standards to be followed, if your company has its own standards that you want followed, your expectations for code documentation, etc. Another suggestion would be to include as part of your weekly deliverables, or once every couple of weeks (at least at the beginning of the project), code reviews. Have the developer explain why they wrote something in a certain way. Also, if you expect architecture to be done as part of the project, or if you are not providing it, have the developer document the architecture and send it to you for your review, then have a discussion on it before the developer goes forward and starts writing code. Following a few simple methods of getting to the goal of having good code, can eliminate the “bad code”, and the frustration that goes along with it.

Categories: entrepreneurs, Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams |

27
NOV
2011

CEOs “9 reasons your VP of engineering will give for why working with a remote software development team will not work!” Reason #4

Comments (0)

I originally published this series back in 2006, but recently I have heard some of these reasons again for not working with a remote software development team, so I thought I would repeat at least part of this series.

The first one I wanted to review again was what I had listed as Reason #4 – We have to be working when they (the remote team) are; we have to be up at the same time as they are in order for this to work.

What this means: The concern is that if we are not working the same hours as the remote location, they (the remote team) will not really be doing any work.

What do they mean? The remote team could not possibly be working during their normal business hours and actually get work done without us being in constant contact with them.  We do not have time to do this, we do not see the value in doing this, and we can do all work ourselves faster.

Actions to take: Engage in a conversation with your VP of Engineering revolving around the following topics: Do you often answer questions every hour for your in-house software engineers? Can they work on their own at all? There should be no question that would stop a remote team from getting any work done for an entire day.  The same as your in-house software engineers are able to grasp concepts and move on and work on their own, you want your remote engineers to do the same thing, to take initiative and show independence and innovation in their work. Foster that type of independence and initiative by holding them to deliverables and coming up with solutions, rather than pinging them every hour to see if they are at their desk and working.

I know persons who think they have to be working at the same time as the remote team.  I have managed remote teams for years, and I never do this. Why, because it defeats one of the major benefits of having a team working at opposite hours from you. They can be doing work while you are sleeping and vice versa. I do not mean working on the same code, but this could be testing in one location and writing code in the other, or writing requirements in one location and reviewing them in the other location, etc. If you are working opposite hours, you can always have results waiting for you in the morning. It also does not wear you out. It is not easy to keep an overnight schedule in the US and still keep up with your family and the rest of your life. The same goes for the offshore location, do not force them to overlap their entire work day with yours (unless of course it is a call center and they are supporting customers during the work day in the US). You will lose a major advantage in this way.

Categories: Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams |

23
AUG
2011

A “Twist” on Trust and “Drinking Your Own Champagne”*

Comments (5)

We talk a lot about trust when building relationships and the added importance of this when working at a distance. When you start out working with a new team or person or persons, who are remote from you, you are always wondering if they are going to get done what they said they were going to get done. Are they really working over there? Trust builds over time as they start to deliver product and start to prove themselves. But this makes me wonder, in addition to technical skills, domain expertise, etc., are there other characteristics of your potential service provider that you can be looking for?

There has been a lot written about the type of characteristics good virtual team members should have; communicative, willingness to share, etc. But most of what has been written comes from the view that everyone, or almost everyone, is working alone, but in different locations. Often, however, that is not the case. It is more likely that several persons are working together in multiple locations; a group of three here, a group of two here, a group of ten here, several persons working alone in different locations, and so on. This will be the case for you when working with a new vendor. They will have multiple people, most often in one location, and you will have multiple people on your side, working in one location. Having multiple co-located groups which need to work together brings on a different dynamic than having everyone working alone in their individual locations. People working alone (usually but of course not always as it depends on the person) are going to be more likely to want to share and find out what other team members are doing, and find out about those other team members, because they have little or no social interaction with other team members where they are located. When several persons are co-located, it can be much harder to get them to want to work with other distributed teams unless there are specific processes put in place for sharing information and for getting to know each other.

It is a given that most of your team members, from your service provider, will have experience working in a distributed manner with other clients, before starting to work with your company. But how do individual team members really feel about it? When you talk with individual team members, asking technical questions is of course a given, but there may be some other questions you will want to ask: “What would you do if you had to work in an office by yourself, and the rest of your team members had to work in another office? How would you get your work done?”

It is not something you think about often, but you would be surprised how many would answer, “having to work with a group in a different office is too hard!” Or another answer you may hear is, “it is easier to work with someone sitting next to you”. What??!! If they have that attitude, do they really have the right attitude to do what they are asking you to do, which is work at a distance?

It is like Oracle not using its own products or Google employees using MS outlook for their calendar….. If they can’t believe in themselves enough to get work done in a distributed manner, within their own company, how can you expect them to get your work down with your company in a distributed manner? Think “eating your own dog food” or “drinking your own champagne” (the latter of which has a more pleasant appeal, at least for me), but for service companies.

So the question is, can the fact that a service provider “drinks its own champagne”, help you?

Does it mean they are trustworthy? Certainly it is not a 100% guarantee, nothing is, but it does show that they understand what it will be like for you. They have internal practice at dealing across locations, as well as experience working across locations with their clients. It can go a long way towards your feeling like you can give them trust. They should also be able to help you better transition to working in a distributed manner.

And really would you want to work with a service provider who doesn’t do, or hasn’t done what they are asking you to do; i.e. give up control, and work remotely?

*Reference “Drink your own champagne” – http://en.wikipedia.org/wiki/Eating_your_own_dog_food

Categories: Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams |

24
MAY
2011

Business expertise versus technical skills!

Comments (4)

In talking with a group of product managers recently about working with distributed software development teams, where part of the team was in the US and part of the team was in an offshore location, there seemed to be a big consensus that one of the most difficult issues in working with the offshore team was getting them to understand the “business side” of the system.  For example one person was very vocal about the issues with the developers in the offshore location not always understanding why the payment system needed to work in a particular way, or why the users needed to work in a certain way.  Other examples came up with billing systems and with the developers not understanding why sales commission had to be calculated in a certain way. This got me to thinking as to why this could be occurring?

According to the group of product managers the reason was specifically based on the fact that we are exposed to “how certain things” work more often in the US than in some of the offshore locations.  I agree this can be a factor with understand such things as “calculating sales commission”. Well at least the basics of calculating sales commissions, because as many people know there are many many ways to calculate sales commissions. It can greatly vary by company. So any developer would need to know what is the algorithm/s used by the company. 

After thinking about this question for a while, I started to think about how many companies search for outsourcing partners. A top priority for many companies is technical skills, which of course are very important when choosing who to work with. But I think sometimes technical skills are given a higher priority than if the outsourcing partner has related business or experience with your vertical market.  For example if your company is in the payments space, working with an outsourcing partner which has experience in that space will go a long way towards helping to overcome issues with understanding how the system has to work. Many companies when they start to look for a partner, are thinking, well we have the domain expertise, we are the experts, which is definitely true, and we can help pass that expertise on to anyone that we work with.  What we don’t have is enough technical skills.  If a company makes a concerted effort to pass on the needed domain expertise then the combination of your side having the domain expertise and the vendor having the technical skills, can work. However, in a distributed environment, passing on the domain expertise will take more effort, and it is easy for it to fall by the way side. It seems to make sense then to give, if not equal weight to both business domain expertise and technical expertise, then at least put business domain expertise in a close second place, when choosing a partner to work with your firm on software development.

Categories: Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams |

5
JUN
2010

Another “feeling” situation and possible ways to deal with it!

Comments (0)

Today I wanted to continue our discussion on the “feeling” type of concerns when working with a remote software development team.

For dealing with the situation, “He/she said yes he will do it, or he said he understands, but I have a feeling he/she doesn’t really understand,” I believe it can be handled in a similar manner attempting to obtain concrete data to support or not support your feelings. This feeling can be common when dealing with remote teams located in different parts of the world. If people are dealing with English as a 2nd or 3rd language they may not ask as many questions as you would like which would show they are thinking about the request, or that they understand. The person could be not as comfortable with their English skills to ask the required questions, or they could just be quiet in general, or it could be that they are afraid to ask too many questions because in some cultures it would not be good to question the client. Therefore it is going to be up to you to dig in further and help dissipate your “feelings” that there may be a misunderstanding. There can be several ways to start with this. Ask your remote team to “write down” was is discussing during status meetings and send a recap to everyone in the team, after the meeting. Review these notes to see what is understood or where there may be issues. There is also nothing wrong with asking a team member to repeat what they heard while you are in the online meeting or on the conference call, etc. This request can be validated by simply saying that you just want to make sure everyone is on the same page. No one should have a problem with this type of request for better communication. If you are not satisfied with the oral delivery of what the developer is to do, ask them to put it in an email or an IM. These types of steps should help the PM determine if additional explanation is needed for a particular task. If you now believe you have done all of the explaining you can do, and the developer has explained what he/she thinks should be done, you should at least have concrete evidence as to the level of understanding; i.e. here is what I told them they needed to do, and here is what they think they have to do and the two do not match. If that is the case, it may be time to talk with your vendor about the situation. You may need to make a team member change or you, and your vendor, may need to dig in more deeply as to why there is a disconnect. The last step should bring even more concrete evidence one way or the other. Once the developer starts to actually work on the feature or request, you will also get concrete evidence as to whether or not the developer understands what they are doing. More relevant questions should come up, plus you will be able to look at actual code and very quickly you may be able to look at actual results. All of these results will either help validate or alleviate your feelings that there is a misunderstanding.

I have one more “feeling” situation I want to talk about next time.

Categories: Outsourcing Offshore, Outsourcing SMB's, Outsourcing Ukraine, Project Management, Virtual Teams |