This link has been bookmarked by 70 people and liked by 1 people. It was first bookmarked on 06 Sep 2006, by Kuniyasu Guan.
-
30 Oct 15
-
18 Sep 15
-
17 Mar 15
-
25 Jan 15
-
the science of control
-
Agile methods downplay documentation from the observation that a large part of documentation effort is wasted. 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. That's a price in the time for people to write them, the added time because it's harder for people to understand many things from a document, and also a price in frustration when people are using them.
-
-
09 Dec 14
-
03 Jun 14
-
07 Jan 14
-
21 Mar 13
-
Building software off just a list of requirements misses out a lot business context - developers are told what to do without being told why it's important
-
Ambassadors are an important part of trust building
-
a partially developed system can also educate the customer, for often there's a difference between what's asked for and what's needed - and usually that's not apparent until there's some working software
-
regular integrated builds allows a US customer to pull down last night's work and try it out
-
important for both sides to give and take in picking the time for calls
-
When we do split an effort with onshore and offshore development teams, we do this along functionality grounds rather than activities.
-
An important part of this is to grow the analyst part of the offshore team. The more someone local to the developers understands of the business, the more the development team can develop efficiently.
-
separate distributed teams by modules that are as loosely couples as possible
-
But many technical decisions need a broader strategic context - so it's important for the remote team to have a broader picture of the direction the project, and the business, wants to take.
-
Rates are only one component of costs, and in any case you have to look at the entire return on investment
-
even if an agile approach suffers from the communication difficulties of offshore, it's still better than a documentation-driven approach
-
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
-
anyone doing it because they think they'll get cost savings similar to the rate differences is seriously deluding themselves
-
-
25 Jul 12
Chris AndersonNice medium-short article...
agile development offshore outsourcing offshoring software management project management
-
25 Jan 12
-
15 Sep 11
-
07 Sep 11
-
25 Jul 11
-
23 Mar 11
-
25 Jan 11
-
It's generally accepted practice that if you commit changes to the mainline, you should not go home until you have received the email message from CruiseControl that says that your changes resulted in a successful build.
-
-
16 Dec 10
-
One of the benefits of a business-oriented ambassador on the offshore team is that it helps provide business context to the offshore team. Building software off just a list of requirements misses out a lot business context - developers are told what to do without being told why it's important. The why often makes a big difference in doing the what properly.
-
A special variant of the seeding visit is important if you have developers on multiple sites from the beginning. In this case it's important to 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, it's important to have proximity during this period. Without this you can get a split where different teams make different decisions, or one team makes a decision that the other team doesn't understand.
-
One of the hardest parts of introducing agile methods into an organization is the cultural change it causes. Indeed we've found that this is the major reason why organizations have problems with adopting agile methods. Many companies operate with a command and control model which assumes that seniors make decisions and lower level people carry them out. To make agile methods work you need much more autonomy and decision making by the doers.
-
But there is good news. Once people realize they have the freedom, and the responsibility, of making decisions - they seem to really relish it. Several of our Indian team told me how their friends in other companies cannot believe how much autonomy they are given. This autonomy is a great motivator, allowing people to be both more productive and able to grow into greater responsibility. Offshore team members gain the trust the understanding to make decisions instead of waiting for the onshore team, which lead to a lot of delays. For me one of the most interesting things we will discover is what the longer term effects are of this cultural impact, both in Asia and in the West.
-
We've played around with various ways to hold common information, our favorite so far is a wiki. Wikis work well because they are simple to use, can be worked with any browser, and are simple to set up.
-
Increasingly I've found that more mature XP teams use acceptance tests as ways of communicating requirements. Such teams get test scripts written out before the start of an iteration to help clarify the requirements and give the development team a concrete target to aim at. 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.
-
On an agile project, the close proximity between customer and developer allows the customer to monitor progress much more frequently, which allows them to spot misunderstandings more quickly
-
Having regular integrated builds allows a US customer to pull down last night's work and try it out. While this isn't quite as immediate as co-location, it still allows the customer to correct any misunderstandings quickly; as well as allowing them to refine their own understanding of the requirements.
-
-
15 Dec 10
-
09 Nov 10
-
20 Sep 10
-
15 Jul 10
-
12 May 10
-
17 Mar 10
-
04 Dec 09
-
06 Nov 09
-
26 Oct 09
-
24 Jul 09
-
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.
-
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.
-
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.
-
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
-
vital, but not enough
-
Ambassadors are
-
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!
-
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.
-
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.
-
-
18 Mar 09
Lakshminarayanan VenugopalUsing an Agile Software Process with Offshore Development
-
30 Dec 08
-
10 Dec 08
-
04 Nov 08
-
21 Oct 08
-
07 Apr 08
-
11 Jun 07
-
18 Apr 07
-
19 Mar 07
-
10 Jan 07
Patrick ScheuererFor 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 fir
offshore agile management outsourcing projectmanagement methodology development
-
05 Jan 07
Tom McLeodStraightforward, but a good list: CI, wiki, separate by functionality not activity
-
19 Dec 06
-
18 Dec 06
-
12 Nov 06
-
12 Sep 06
-
26 Jul 06
-
19 Jul 06
-
18 Jul 06
-
14 Feb 05
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.