Dmitry Serebrennikov's List: Outsourcing

• we ask for a daily "standup" or "scrum" report - an online form that takes 2 minutes to fill out and lists "What I did", "What I will do", and "What I need."l

• In your writing on your blog, you seem to imply that a remote Scrum team can be as productive or MORE productive than a co-located team. Explain how and why.

  It can be more productive because you don't waste time traveling or commuting, and you have access to some of the best talent available globally.

• MikeB, it can work if you assume that the specification is not fixed. At Assembla Consulting we work on fixed cost, fixed timeline development projects, and here is how we quote it.   

  First, we make a roadmap, a list of features sorted in priority order. Whenever possible, we pull features apart so that we can deliver a simple feature first, and add to it later.  
   
  Then, we read down the roadmap and we draw a line under the minimum feature set that we think will make a useful release. That's our guarantee. We take some risk to guarantee that you will get that much, within a fixed budget and timeline. There should be a high probability of going considerably beyond with the same budget and timeline.  
   
  Then, we decide on a timeline that includes a first useful build, a beta release, and usually, a full production release. These timelines range from 8 to 26 weeks, and typically are more controlled by the business schedule than the development team.

  Then, we design the team or "level of effort" that we think we need. Admittedly, this requires a rough estimate of the work to be done. The team has a certain weekly cost.  
   
  The budget is equal to the cost per week, times the number of weeks. 
   
  Then, we work on the roadmap in order. We assume that the roadmap will change approximately weekly if we see opportunities to improve the product. We release daily for the development team, weekly for the client, and to bigger groups on the dates promised. We try not to make a decision about when to release, but instead, discuss who should see the release, depending on its level of maturity.  

  • Very interesting method. Need to try it some time.

1 more annotation...

• So far we've discovered  that we can make it work, although the benefits are still open to  debate.
• "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
• It was very important to us that we retained our very high hiring standards (typically we only offer jobs to about 1 in 100 applicants)
• Use Continuous Integration to Avoid Integration Headaches
• Everyone has been delighted with how well this works. Its main benefit is that problems that plague other groups with integration just don't happen to us.
• Although world-wide Continuous Integration is resoundingly popular, we have run into some problems. Communication pipes aren't as wide and reliable as we'd like, so many source control operations can get awkward from a remote site. In general we keep the build servers in the same site as the majority of developers, but remote sites can find it takes an annoyingly long time to get a fresh update from the mainline.

  • Distributed scm systems might be better. Like git and its more civilized brethren - mercurial, etc.
• st too. Continuous Integration requires good connectivity,  often better connectivity than people are used to.
• Have Each Site Send Ambassadors to the Other Sites
• From the beginning we decided to ensure that at all times there was someone from the US team present in India to facilitate the communication. Such an ambassador already knows the US based people and thus adds his personal contacts to help everyone communicate.

  • Yea, we had Manoj, but that didn't really help that much. Or was he not there when the bulk of development was going on?
• We found it useful to send a US developer and a US analyst to India to communicate on both technical and requirements levels.
• One of the benefits of a business-oriented ambassador on the offshore team is that it helps provide business context to the offshore team.
• An important part of the ambassador's job is to communicate gossip. On any project there's a lot of informal communication. While much of this isn't important, some of it is - and the trouble is that you can't tell which is which. So part of an ambassadors job is to communicate lots of tidbits which don't seem important enough for more formal communication channels.

  • Hm. Interesting.
• rotate the ambassadors every few months (and in  some cases every few weeks)
• if an ambassador spends too long abroad they lose contact with home
• Much of a project manager's job is to help resolve conflicts and flush out problems before they become serious. Experience working on both side of the telephone line is really important for them to do that effectively.
• Use Contact Visits to build trust
• Ambassadors are
• vital, but not enough
• You can think of two kinds of contact visits: seeding visits
• maintaining visits
• It's important for seeding visits to be working trips, since the whole point is to get people used to working with each other, so they should be arranged around some joint task.
• primary purpose of the visit isn't to do the task, but to the build the working relationships.
• keep the work pace relaxed
• Dinners and sightseeing can often be the most useful activity that the visitors do with the hosts.
• It is important to get seeding visits in as soon as you  can.
• get the developers, or at least the  senior developers, together to build the first few  iterations. It's in these iterations that the crucial  architectural decisions will get made
• Don't Underestimate the Culture Change
• Beware that polite acceptance is often a sign of an  important issue not getting discussed.
• The bad news for this is that getting teams to be more pro-active is an uphill battle, and one that inevitably takes a lot of time. You can never assume that problems will be raised, even when they are spotted. Getting people used to a distributed control style of management takes longer than you think.
• Use wikis to contain common information
• someone needs to act as a gardener to make sure it doesn't get overgrown.
• Use Test Scripts to Help Understand the Requirements
• One style that's worked well is for a US based customer to write a short narrative (a couple of pages) to flesh out a feature (story in XP lingo). An Indian based analyst/tester then creates test scripts for this story. This can be done either for automated or manual testing, although we very much prefer automated tests. As the scripts are developed the US and Indian analysts coordinate by email and IM as well as regular (2-3 times a week) conference calls to review the test scripts.
• Use Regular Builds to Get Feedback on Functionality
• Use Regular Short Status Meetings
• Time zones are often the biggest problem here
• In our more recent projects we've made a greater use of the  wiki, and this has reduced the need for cross-shore  stand-ups. Now we do stand-ups within a shore's team, but not  between the different shores. We do however do daily cross-shore  meetings, but these don't involve the entire team - just those  who focus on the cross shore collaboration. With small teams,  however, we do do the cross-shore stand-ups.
• We've found that it's a good habit to start conference  calls with chit chat on local news.
• remember that  holidays are rarely shared, so you'll often get times when one  team is in holiday mode while another team is in a regular  work week.
• At ThoughtWorks almost all projects use iterations of one or two weeks in length.
• Use an Iteration Planning Meeting that's Tailored for Remote Sites
• When Moving a Code Base, Bug Fixing Makes a Good Start

• Separate teams by functionality not activity

   

  Much of the traditional thinking on the onshore/offshore boundaries is based on the activity that people do. So analysis and design is done onshore, construction done offshore, and acceptance testing is done onshore. This obviously fits well with the waterfall model.

  We've found that contrary to this, matters improve when we make the offshore team handle as many activities as possible. So we prefer to see them do as much analysis and design as possible, subject to the limitations that the requirements are coming from onshore.
• grow the analyst part of the offshore team
• Expect to need more documents.
• Documentation, however, becomes more important with offshore development since the face to face communication is reduced. This work is, in a way, a waste since it wouldn't be needed if the whole team was co-located. But given the offshore model, you need to do them - so they are part of the price of doing things offshore.
• There are two keys to successful documentation on agile projects. The first is finding the point of "just enough" documentation. This is difficult to determine and will vary by project. Fortunately, the iterative nature of agile development allows you to experiment until you get it right. The second key to successful agile documentation is to not get attached to it or have unrealistic hopes of keeping it updated. Documentation must be created to serve a specific purpose, and after it has served that purpose you'll all probably have more important things to do than keep updating the documents. It may seem counter-intuitive, but it's often better to produce fresh documentation the next time some is clearly required. A side benefit of starting over each time you need to document part of your project is that it's great incentive to keep your documentation efficient!

  • Bingo!
• Get multiple communication modes working early
• We've found a lot of value in video  presentations. Short lectures about the background of the  project that can be recorded and sent over to the remote  team.

  • Excellent idea. All brown bags should be recorded. It's great for new hires on and off shore.
• They aren't so good for details, but work better for  a broad picture.
• Email can often be a mixed blessing. In particular we've found that it's good to discourage person-to-person email in favor of broadcast newsgroups or mailing lists. It's too easy for a piece of information not to go to someone who needs it, or be unable to find it. By posting messages and requests in a newsgroup, everyone can see the messages and it's easy to search. People find it easy to skip over threads that they aren't interested in.
• Costs and Benefits of Offshore Development
• Most people in the software industry know, or should know, that productivity differences between developers are far greater than salary differences - and even the rate differentials offered by offshore aren't necessarily greater than that. Offshore work also introduces extra costs and risks that may offset the rate differential.
• Of course a high ceremony organization that uses documents as the primary communication mechanism will not suffer as much from this. Essentially their communication has already taken all the damage from lack of direct contact, so the offshore effect is less notable.
• Another benefit of offshore that's coming up is the use of 24 hour development to reduce time to market. The benefit that touted is that by putting hands on the code base at all hours of the day, functionality gets written faster. Frankly I think this is a totally bogus argument, since I don't see what adding people does in India that it wouldn't do by adding them to the onshore team. If I need to add people, it's more efficient to do it while minimizing the communication difficulties.
• The nugget in the 24 hour development idea is that despite the tech slowdown it's still not easy to get talented developers. So often you can't get enough talented developers in the onshore location, so an offshore team is valuable for their talent rather than any lower cost.

• The Future of Offshore and Agile

   

  As I write this, offshore development is very fashionable, but it's still too early to really understand its true strengths and pitfalls. Certainly anyone doing it because they think they'll get cost savings similar to the rate differences is seriously deluding themselves.

55 more annotations...

• Calen Legaspi

   

  I'm CEO and co-founder of Orange & Bronze Software Labs. I'm on the board of directors of the Philippine Software Industry Association (PSIA), and head of the PSIA Technology Council. I'm one of the founders and the current President of PinoyJUG, or "The Association of Filipino Java Developers". I'm a Sun Certified Enterprise Architect, Sun Certified Web Component Developer, and Sun Certified Java Programmer.

   

   View my complete profile

  • This looks like a serious guy to work with in Phillipines.
• G2One, maintainers of the Grails framework, and SpringSource
• By far however, we've found the most practical framework for enterprise applications to be Groovy and Grails, mainly because it was based on mature technologies like Spring and Hibernate.

• Compensation & Benefits Comparison
  

  First of all, let's start with just a compensation and benefits comparison. When doing your calculation for an onshore hire, don't forget to include the cost of such benefits as social security, healthcare, pension, time off and even bonuses. According to Salary.com (as of this writing), the total average US compensation and benefits package for a Java Developer comes to $112,435 a year.
  
  An offshore Java Developer in the Philippines, India or China, on the hand, usually costs somewhere around $20/hr, or around $40,000/yr. This is all-in since you don't cover any benefits. Your savings on comp & ben alone is $72,435/yr per developer, or 64%.

  • Hm. That's no 5x at all. And this is a proponent and a professional in this business in the Phillipines.
• reviewing work the next day and trying to correct errors via email just doesn't work
• Your vendor must already be experts in the bulk of the technology you use.
• The vendor should have a very strong CTO, or better yet, a strong team of seasoned architects.
• The vendor should have its own group of mentors and pinch-hitters who can oversee quality, mentor the more junior developers, and conduct their own internal training programs.

6 more annotations...

• Benefits of Distributed Agile Development
  

   

  1). Lots visibility and transparency

   

  2). Were able to deliver work fast enough with acceptable quality

   

  3). Offshore team enjoyed agile/scrum, especially the intense collaboration with each other

   

  4). Not one "onshore" resource lost their job
• They did a lot of risk analysis and thought of everything that could go wrong: communication, source code violations, connectivity, etc.
• Held both teams to the same standard

1 more annotation...