Written by Sibers CEO Serge Markov
Martin Fowler, “author, speaker, consultant and general loud-mouth on software development” described his experience with offshore development and using agile practices, which we apply in most our projects, as follows:
“For the last four years ThoughtWorks has operated a lab in Bangalore India to support our software development projects in North America and Europe. Traditional approaches to offshore development are based on plan-driven methodologies, but we are very firmly in the agile camp. Here I discuss our experiences and lessons learned in doing offshore agile development. So far we’ve discovered that we can make it work, although the benefits are still open to debate.” (see the article)
Let me express my opinion about practices he described
When development force is involved on both parts, we propose to use one repository for code base – and make daily builds. Unfortunately, some day one side can discover very large changes there (like we found getting back to work a few days ago). Getting small and manageable updates is vital!
We haven’t used much this practice here in Sibers, but at one my previous jobs (for CFT Inc) it worked nicely: we spent several weeks to get things resolved remotely and then found a solution by sending a small team to the customer site. Communicating face to face with several stakeholders we could find the solution in terms of hours.
We always welcome our prospective or current customers at our headquarters here, in Russia. If it causes some trouble to get a Russian visa, it’s possible to meet with us in a visa-free country (like Turkey or Kyrgyzstan, where we have our partner company KG United).
Culture really matters! Fortunately, Russian world is much closer to the Western one than the latter to that of India or other Asian countries. At least you won’t face a culture shock with us.
We do extensively use WiKi’s for our internal KnowledgeBase, and several our projects also use this practice, which proved to be quite efficient. Suppose we need to make it permanent in all the projects.
Our QA team has great abilities to automate acceptance testing via tools, but also for several large projects the development team creates a big set of test-units written by themselves just to cover all possible behaviors of the application.
I do appreciate this practice very much. In 20% of projects we make daily builds, in 60% we make builds or provide online demo 2-3 times per week (but still send daily email updates and do chat with customers). It really works!
Usually this practice is applied through daily chats via IM – ICQ, AOL, MSN, Google Talk, Skype or any other preferable to the customer way.
Depending on the project size, our iteration varies from a day to week.
Every our project starts with an “architecture” meeting where the whole team is involved: CTO (who made the estimate), Sales Manager (who led a preliminary discussion with the customer), Project Manager, Senior Developer or Team Leader (with clue on technology to be used), Developer and QA Engineer (to ensure quality questions resolved from the start).
We make a lot of projects with existing code, and “a few changes” very often transform into large development as we begin with fixing existing bugs.
In several large projects we found that it’s better to get a whole team involved into the whole architectural part – both with analysis, design, development and QA. In such a way the team understands the whole concept of the project and works more efficiently.
Agree! At least one practice describes this rule: when our sale process is finished, we do require Sales Manager to prepare a Work Statement document with all known details about the project described. This document is the base for work on the project and a good example that things should be written down.
Our PMs do use several methods described bellow. Probably it’s kind of duplicating information, but it’s necessary when you cannot “look into your customer’s eyes”:
- Oral – we have 1-800 number and conference calls software based on Asterisk and VOIP technologies
- Quick chats – IM’s as described
- Email – daily updates, reports, financial information
- Bug-tracking – bugzilla, Mantisse or whatever preferred by customers
So sum it up:
- In most cases HireRussians and Sibers follow these practices, which are of course not “rocket-science” but the essence of everyday software development experience.