Posts Tagged ‘managing remote software developers’


How Going Slow Can Actually Speed You Up

Comments (0)

As many companies can attest to, it matters less and less where software developers are physically located. Working in a distributed manner with somebody halfway around the world is almost the same as if they were in the next building as communication is disrupted in either case. But there are some key differences to building an internationally distributed software team, and working with them for the long term, versus building another team in the building next door.

U.S. companies are accustomed to expanding internal teams by figuring out how much work is required for a project or how much is in the pipeline for a particular system, and how many programmers will be needed to complete that work; they then immediately hire the full allotment of programmers (assuming budget allows). There may be an onboarding process for new team members which may involve having new team members complete a training course, or work with a mentor, etc., but the main emphasis is on technical skills. These types of companies come to Softjourn eager to “start up a remote team,” believing that everything is going to be wonderful once they have 10-25 top level programmers on board. When you work with a remote team, however, assigning a full team of developers from the very beginning is often impractical and can cause inefficiencies that plague a development team for its entire lifecycle; especially if this is a company’s first foray in to working with a remote software development team.

At Softjourn, our process for helping our clients build software development teams is different but simple: prepare, construct, produce then expand. This means that we build a team on a solid foundation before expansion. If your company truly wants their remote team to be a part of your company, to work directly with another team of software developers who work at your company headquarters, or in other locations around the world, etc., more time and more of a process is needed to bring remote developers in to your company culture. Helping them understand your product and your clients takes effort, getting both sides (your existing software developers, QA Test engineers, product managers, escalation engineers, etc.) comfortable and trusting each other takes time, and this is much easier when you start with a small and focused team. Start with a small team, get the process right, and then expand. In addition to allowing for a more efficient initial training process, this lets the team itself select the right people for the team, to train new members as they are added going forward, and gauge their productivity. As well, your current in-house developers have to get used to working with a remote team. Processes have to be in place for communicating effectively with a remote team, to introduce and get them and everyone comfortable with communicating and working directly, to set realistic expectations for the team, etc.

Every aspect of our system is designed to work for our clients. The key advantages to this process are:

– Every single developer working on your project fully understands the objective of your application, why the users work in a certain way with the application, etc., and is able to communicate the objective to the other members of the team.
– Your in-house team feels comfortable working with your remote team, both to contact them directly, and with the level of productivity of the remote team.
– The team gains momentum as they move forward, completing work faster and faster, as they become more and more familiar with your system. They also are able to provide input to the design of features, and require less and less of your input in order to be able to understand how your company expects features and changes to be designed and implemented.

Once you get to this point with a remote team, you can start adding people. The remote team will be able to identify the right people to add to the team, those that will fit in with the team culture you want. One of the worst things you can do is to start to develop remote teams in multiple directions at the same time (for example, for multiple products, at one time), without having the process at least working for one team. You can expect that there will be just as many adjustments inside your company, with regards to working with the remote team, as there is for the development of the remote team itself.

Distance means that there will be differences when working on joint development, and those differences could cause significant delays in the development lifecycle of a software development team. Taking the time to prepare, construct and produce, before you expand, may seem like you’re slowing things down, but you’re actually solving problems before they even exist – and that improves your ongoing software development from every perspective. For more information on Softjourn’s Prepare, Construct, Produce, Expand methodology, click here.

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


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 |


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 |


Know your Audience!

Comments (0)

Edward T. Hall, an American anthropologist, once said, “Culture is Communication and Communication is culture.”  I usually like to deemphasize cultural issues when relating to software development projects, as it tends to be used as an excuse for why a project can’t be completed or why the project is too difficult to do, however, when talking about the communication portion of culture, I think there are steps that a US software development manager can take towards making themselves more understood and getting their message across, to their development team located in another country.  An important aspect to remember about communicating with a development team in another country is not that they understand or have the right technical skills, and use the right acronyms in the right place, but it is for the development manager to remember the key communication mantra, “Know your audience”.

More people outside the US are exposed to the US culture (either the right or wrong version…..) through American TV shows and films that are widely distributed. However, just because someone knows about Survivor (and most likely their own country has its own version of this show…), or has seen “The Office”, or “The Social Network”, it doesn’t mean they know everything about Americans or understanding American English.  Especially in the US business world where a lot of slang is used, with a lot of references being made to sports which are more widely played in the US than in most other countries (such as American baseball or American football).  When talking with your development team outside the US, it pays to think about what phrases you may be using which may need to be explained. For example, telling your developer he needs to “step up to the plate” when you really want him to take on additional work, may not get you what you want.  Or telling a developer who is critiquing a design choice, not to be a Monday morning quarterback, may not stop his input. Some of this type of conversation comes up in “face-to-face” (be it real face-to-face, or online face-to-face) meetings or these phrases may come out in group emails. Certainly your remote development team will be glad to be included as “one of the team”, just be aware that you may need to circle back and make sure that everything was clear to everyone receiving your message.

Effective communication is not only about choosing the right words and phrases to use, but also about being aware how that information is understood by the recipients.  So remember to know your audience!

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