Archive for May, 2012


Qualities of a Great Service Provider/Partner!

Comments (0)

There have been a lot of nightmare stories circulating about working with remote developers and web-based applications. Many companies describe running into challenges with time differences, language, and the quality of code in the final product. So how do you choose a great software vendor to work with?

Many software services companies promote their use of the Agile methodology, but what’s more important is how they actually employ it. Their ultimate goal should be to collaborate with the client and keep them aware of the work being done. If you choose to work with software developers outside your country, you don’t want to sit and worry about what is happening with your project and feel like there is nothing you can do but hope it is what you asked for.

Softjourn stresses constant customer interaction and frequent deliverables in their use of Agile. This means you will continually see the product as the project evolves, and you will be able to provide feedback and request changes. Dependent on the project time-frame, Softjourn schedules regular delivery dates, so that you can view the progress, as well as weekly conference calls to further involve you in the development process.

Another trait of a great software development firm is their ability to understand a client’s vision. You may not know great code from bad code, but you can envision the end product you need for your business. That’s why it’s so important for a service provider to be able to translate your vision and needs into the appropriate programming and applications. This skill should be easily identified during the bidding process. Offshore developers should be able to take your brief mock-up of the product and requirements and be able to return to you with ideas about how to achieve it along with detailed questions that indicate they really understand you. After all, you are hiring a services company for their contribution of expertise, not to just simply fill an order.

Perhaps most importantly, your service provider needs to prioritize communication. As mentioned earlier, this should be demonstrated by their approach to the Agile methodology: communication with the goal of developing a collaborative relationship with the client. Another factor in communication is responsiveness. Do they always return your phone calls or emails? Do they make you feel like an important client? This is an area in which Softjourn takes great pride. Through strict attention to communication and making the effort to partner with their clients, Softjourn is able to solve problems before they exist. And, to ward off those fears of any language barrier, Softjourn provides the client with a liaison for meetings with the programming team to increase the client’s level of comfort.

It’s important to remember that a software services firm can offer more value than cost-savings alone, if you choose the right company. A vendor that doesn’t make you feel like a small client can mean big returns for your business and your investors. How is your vendor treating you?

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


The Challenge with Dynamic Teams!

Comments (1)

Last time I talked about what could be some of the benefits to a company if they decide to work with a dynamic team, and a dynamic team versus a dedicated team. This time I would like to take a look at some of the challenges for a company when using this model.

To start I want to give an example of a dedicated team scenario and that same scenario with a dynamic team.

Let’s say a company has a one person dedicated team, and let’s say it take a developer two months to get up to speed on the company’s application. Once the developer is up to speed, all is well, and they can work very fast. But then suddenly after one year, they leave. In a best case scenario two weeks are needed to get a new developer in (if one was waiting in the wings to give notice at their current job and start with the company right away – always happens right?), and then two months for them to get up to speed on the company’s application. So the cost to the company in lost productivity could be approximately two months of fully loaded salary while the new developer is getting up to speed plus two weeks with no one available.

Let’s look at that same scenario and how it may differ if the company was working with a dynamic team. One year ago the further development and maintenance of the company’s application was assigned to a 5 person dynamic team. During the first two months all 5 persons touched and got to know the company’s application as a result of working on adding new features and fixing bugs. Knowledge was shared during pair programming, daily status meetings and code reviews. After one year, one of the five persons leaves the team. A new developer is brought in to work on the five person dynamic team and begins to learn the company’s application. There is no loss of productivity while the new person is getting up to speed, as there are 4 other person’s with knowledge of the system.

If you compare the two scenarios then the dynamic team scenario sounds ideal as there is no lost productivity. But is that always the case? What are the challenges or risks in working with a dynamic team?

The biggest challenge that always comes up in discussions about dynamic teams, and the one I want to focus on here, is that in a dynamic team, no one developer gets to know the system inside and out, because they are also working on other systems at the same time. Looking at the scenario above, we can assume approximately 2000 hours of new functionality were added to the system in one year. For a dedicated team of 5 persons, each would have worked on the system approximately 400 hours (it is also assumed of course that they heard about the system via code reviews or status meetings or common discussion of issue meetings, etc., as well), versus 2000 hours for one person, in the case of the dedicated team.

Who is going to know the system better? There can be nothing to make up for the experience gained by working with the same system daily. Therefore we can agree that the dedicated team is always going to gain better individual knowledge of an application, especially in the short term, there is no way around that. But in looking at this challenge we have to look also at the risks or challenges with dedicated teams. One was referred to before in the scenario, the risk of losing that one or two persons who have all of the knowledge. But there is also another possible risk; the downside to daily work on the same system day in and day out. Here I enlisted Anatoliy Okhotnikov, Softjourn’s Head of Software Development, again for our discussion on the challenges with dynamic teams. According to Anatoliy, “Consistency is better for a person who works in some fields of technology, but projects must be rotated to bring in new talent and continually improve developer’s skills. People who work for a long time with a single project become stagnant and their efficiency and effectiveness drops as they start to lose interest and get used to a routine.”

I would have to agree that this could be an issue with some projects and certainly with some developers. Some developers like and need change more often, they like to continually be working with different projects it helps them develop different skills. But there are certainly some who like to work with the same system and really get to know it and be an expert in it. If you are able to find that one or two developers who want to stick around for a long time, that may be the way to go, but is that reality and always possible? As well what do you do when they want to leave, which they will want to do at some point? Whether you choose that a dynamic team is right for you, or if you prefer a dedicated team, will depend on which risk is more acceptable to you; the risk of losing all knowledge at one time, or the risk of maybe not having that go to person or persons who immediately know every single detail about your system.

There is another question I would like to explore some time, regarding dynamic teams. Is there an optimum dynamic team size that correlates to the size of the system that is being supported? Or perhaps correlates to some other aspect of the number of new functions to be developed over x time period? But that is a question for another post!

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