Discussions

News: Tech Talk: Vincent Massol on Agile Offshore Methodologies

  1. In this interview, Vincent discusses how agile methodologies can be used in offshore, collaborative development. He looks at various communication tools used between projects, how two teams apply continuous integration using Maven and plugins such as CheckStyle, DBunit, and Clover. He also looks at how Cactus and Mock Objects can be used for testing and integration.

    Watch Vincent Massol's Interview

    Threaded Messages (28)

  2. If you want to be Agile, don't Offshore!
  3. If you want to be Agile, don't Offshore!


    Yes, agile and offshore are too big trends that appear to be in conflict with each other. It is pretty clear that going offshore is going to make a project less agile.

    However, the issue becomes more interesting if you were to claim, "If you want to go offshore, don't be agile". This is more open to debate. Some companies are going offshore, like it or not. There are many reasons why a company go offshore, e.g. cutting costs, appeasing shareholders, moving closer to clients or other business units. The point is, these are higher-level issues which are unlikely to be overridden by considerations of the appropriate development process.

    So having decided to go offshore, what is the best process to use? With developers removed from the business and/or distributed themselves, a conventional document-driven process seems tempting. But it will be interesting to see how approaches as in the interview, and in "distributed XP" balance things.

    What struck me about this interview was that most practices and tools were the same as would be used in a standard, non-distributed, agile process. I can't help thinking there must be more modifications required to compensate for what must be a huge barrier to agile development.
  4. What struck me about this interview was that most practices and tools were the same as would be used in a standard, non-distributed, agile process. I can't help thinking there must be more modifications required to compensate for what must be a huge barrier to agile development.



    communication tools are of central importance. if the tools or their use, fail, the whole thing falls in a screaming heap.

    regs
    scot.
  5. What struck me about this interview was that most practices and tools were the same as would be used in a standard, non-distributed, agile process. I can't help thinking there must be more modifications required to compensate for what must be a huge barrier to agile development.


    Hi Michael,

    Yes, you're right. The practices are very similar as in non-distributed mode but there are some tuning required. Some examples:

    - Even though we are using short iterations (2 weeks), we need to have the use cases for those iterations very well defined (i.e. in UML for example). this is especially true if the business analysis has been done centrally (i.e. not by the persons doing the development). In XP, you might have meetings to spread verbally the knowledge and only draw the hard cases on some boards. This is not really possible with offshore.

    - Frequent travels are required. We have lots of exchanges on both sides.

    - Most importantly, the teams must have a local coach/project lead. You can't expect to manage directly individual people through the wire. It's not effective and leads to confusion and it emphasizes communication issues due to cultural differences.

    That said, I've found that agile processes help a lot to attenuate the problems due to distance. This is quite normal as agile processes emphasizes constant feedbacks to reduce risks. Whereas succeeding an onsite project may not necessarily require applying agile techniques, I've found that agile methodologies are really useful (I hesitate to say mandatory :-)) for offshore project. Of course to be precise we would need to define what I mean by agile methodologies. I probably only use a subset of all possible practices. My emphasis is on continuous integration and constant feedback.

    Thanks
    -Vincent
  6. "If you want to be Agile, don't Offshore!"

    "Offshore" is not just outsourcing a project to talented programmers in India, China, Russia or France where people earn work for "peanuts". France is a joke by the way, they're not really talented or programmers :-).

    Wouldn't life be great if we could all run everything from a single team working in the same room? Agile heaven!

    Sadly though we don't always have that luxury, it's not just outsourcing that moves things offshore but also companies with worldwide offices, and companies that have partnered with another in another country. Even development that needs to take place partly on a customer site in another country is still technically offshore.

    So, having pointed out a few of many possible "legitimate" offshore situations it would then seem equally legitimate to try to develop them as agilely as possible.

    We have developers in three different countries covering 7 hours of time zone. We use CruiseControl and Maven to manage builds, CVS over SSH for source. SSH for programmers to log into various different machines to run tests since we have client hardware to run performance tests but not in every location.
    We use Tomcat (5) for Cruiscontrol results, Maven sites and Jira which we use for issue and bug management. Jira is the "dog's bollocks" as we say in England, all of our customers use it for product feedback. MoinMoin Wiki for documentation, and Jive for project reporting and customer comments.

    Good stuff Vincent, shame about the accent though :-)
  7. MoinMoin[ Go to top ]

    MoinMoin Wiki for documentation


    LOL, nice name. Moin, moin is only used where I live here in the north but we say it all the day long.

    Moin, moin!

    -- Andreas
  8. MoinMoin[ Go to top ]

    They say it in Luxembourg too, the other funny one was "Multzite" or something like that. I heard it a lot when I lived in Stuttgart.

    MoinMoin is a damn good Wiki, really easy to set up either stand-alone or with a web server.

    -John-
  9. If you want to be Agile, don't Offshore!


    But if you DO offshore, make it agile! (if you want it to work)

    In my mind one of the biggest risks of off-shore/outsourced development is making sure that you get what you want, and making sure that it will work reliably, and that it will be maintainable. Its too easy (due to above-mentioned limitations of communication) for them to develop what THEY think you require, slap together a mess that you wont be able to maintain.

    Frequent Release Cycles - you NEED to know if they are going off-track - they need the feedback to help them understand your problem.

    Continuous Integration - you need to detect integration problems immediately.

    Testing - you want to have some measure of reliability - and you want the tests to be the "ultimate" documentation. You want to be able to maintain the system, so you want to have the safetly-net of tests and you want to have the simplicity that TDD brings about.

    Planning - you want to prioritise the development so that you get the most important stuff first (so you can be confident they know what they are doing - and because only you know what will provide immediate business benefit.

    -Nick
  10. I've been working for the last 6 month on a project in an Agile offshore fashion.
    And also, what was interesting about that project is that open-source is used EVERYWHERE: from the DB to all the frameworks and tools.
    We were using intensively CVS (remote connection via SSH), Yahoo Messenger and Scarab (for issue tracking system) for communication.
    I have to admit that a tool like scarab was probably the most important tool for us bc it help us to keep track of ALL the informations & documents.
    And there is Ant, but Im seriously thinking about moving to Maven.

    BTW, here the result of that project:
    http://www.americandiamond.com
  11. it can work[ Go to top ]

    I was team lead on a short project that developing a stockmarket trading game using all open source tools and a somewhat agile method. (not agile enough in my opinion). the team was geographically dispersed, and I think this causes the communication tools (messenger, email, bug track system, task tracking, project planning etc) and their use to become vitally important.

    One thing i found was that it was difficult to get good feedback from developers if they didn't want to give it to you. when they sit next to you it's easy to see when they are struggling with something. but when they are remote, you don't see the body language so easily and sometimes you don't pick up on things quick enough. it is people's natural instinct to tell you everything's ok and not to admit to lacking understanding or being at an impasse because they feel it is an admission of failure. whereas in a normal team you can pick this up without having to be told, "i'm not sure what's going on".

    will there ever be a transcript of this? my work won't let streams in through the firewall.

    but having experienced doing it i'm not going to knee-jerk the whole idea, unlike some others.
  12. I wonder about the naivity of programmers these days. More often, the question is not how can we make offshoring successful but rather what can we do to sabotage it.

    Much like religion, Agile methodology can be used to dupe workers into teamwork, even when it is not in their best interest.

    In the old days, programmers use to joke about writing nasty, undocumented code to retain job security. Well, it is now a real political issue. Offshoring is not a fate we should just learn to accept. Certainly, the fat cats would like us to think so. However, it is something we have control over, as long as we recognize that the many opportunities available for political action.

    Now that unions have become useless vestiges of the past, we have to resort to subtler means of coercion than going on strike. We need a methodology that is designed to protect the worker from corporate greed, one that embraces deceptive communication tactics, e.g. writing gobs of documentation that appear to transfer knowledge generously but really provide useless fluff with sutble gaps and misleading inaccuracies.

    If you think the company you work for is your friend, take another look at the employment agreement you probably signed, the one that strips away your right to sue or retain copyrights to anything you write outside of work, even a love poem to your girlfiend.

    Also, consider the way many companies maximize their profits not by producing great software but by selling "maintenance" contracts for correcting flaws in crappy software sold for pennies. Not so different from Mafia protection, I would say.

    I ask all you naive programmers, should we not treat these companies any differently than how they treat their customers and their employees?

    I happen to like Agile methodology, but I just don't feel that it is appropriate in adversarial situations like those that involve American workers getting screwed by offshoring contracts.

    In fact, I would suggest that we convince management that reaching CMM level 5 is the only way to make offshoring successful. They'd probably fall for that. Let the offshoring projects get bogged down in bureacracy. Let's keep Agile methodology for times where we want to succeed!
  13. <none none>
    In fact, I would suggest that we convince management that reaching CMM level 5 is the only way to make offshoring successful. They'd probably fall for that. Let the offshoring projects get bogged down in bureacracy. Let's keep Agile methodology for times where we want to succeed!
    <none none/>

    He, he !! Excelent idea !

    Also, take a look :

    http://www.nytimes.com/2004/01/06/opinion/06SCHU.html

    BTW, im from Brazil. We can take some projects too and we are waiting for the promisse of "Free Trade Commerce". Then may be we could sell some orange juice, airplanes, and off course, some bananas too ! :)

    Work in IT areas or wharever product you can imagine isn't a birthright so let´s start to finally change the way we think the world.

    Rodolfo
  14. Off-shore development[ Go to top ]

    Well-said.
  15. Communication, communication!!![ Go to top ]

    It's funny to read about agile off-shore methodologies when we have been applying them for more than two years. 90% of the tools and practices described by Vincent are EXACTLY the some ones used by us. It seems to be the right (and only?) way to success.
    The biggest challenge was not the technical challenge, it was the management of remote teams. Management of people from different cultures (China, Canada, India, USA and Spain), from different time zones (9 hours of difference between Vancouver and Madrid!) really broke my nerves!
    But Vincent, please, don't tell me communication is easy with all these new tools, because I don't care about wiki, instant messaging, video conferences... pick up the receiver and dial up, that's all! The problem is that... I almost went to bed when the guys in Vancouver started working!
    Time zones is the biggest problem of offshore development. South Americans... you should get a lot of offshore development from USA due to this problem!
    I know this problem very well, because I start to work after 10:00AM in order to have a couple of extra hours of overlapping with my colleagues in California.
    Regards
    Diego
  16. Hi Diego,

    > The biggest challenge was not the technical challenge, it was the management of remote teams. Management of people from different cultures (China, Canada, India, USA and Spain), from different time zones (9 hours of difference between Vancouver and Madrid!) really broke my nerves!
    > But Vincent, please, don't tell me communication is easy with all these new tools, because I don't care about wiki, instant messaging, video conferences... pick up the receiver and dial up, that's all! The problem is that... I almost went to bed when the guys in Vancouver started working!

    [snip]

    I've never said it was easy, have I? :-) What I'm saying is that using agile practices makes it easier (see Nick's post which is exactly to the point). I agree that cultural gap is hard and only improves with experience on both sides (what I call offshore-ability of people, which has to be groomed and developed). BTW, this is one of the reason why using a good Pivotal Provider with experience helps (you can also discover it to yourself but it'll take longer).

    WRT timezones, I haven't much experience as I've been working on 2 big offshore projects for the past 2.5 years and they were between Europe and India (only 4.5 hours of time differences). It isn't at all a problem for us. The offshore team is coming to work late and leaving late which gives us a good overlap (there's only about 2 hours of isolation). I'm sure it's harder with greater timezones.

    WRT the "new" tools: on our project people are using chat about 80% of the time they're communicating. It really helps. Picking the phone is good from time to time but cannot be done all the time, at every minutes, for different reasons:
    - it is expensive
    - the line quality is not always good and it is sometimes hard to understand the other person clearly (especially if they speak a language that is not your native language)
    - but more importantly, it is *disruptive*. The person at the other end has to answer right away even if he/she's doing something else. With chat, it doesn't happen.

    I'm not saying you shouldn't pick up your phone. We do pick it up roughly twice a week per person but the rest of the time we use chat/email/wiki/cvs/jira/trips/etc.

    Thanks
    -Vincent
  17. Actually, it was like a pain in the *** when I started with daily conference calls with chinese developers, with very poor english, we decided to start using the email. Since the development teams almost never overlapped, instant messaging and chat could not be applied. I'm working in a new project, and instant messaging really works, but the 'voice language', just like the body language, it is really important. Normally, messages written by non native english speakers sounds rude, even though the intention is not to be aggresive.
    Everybody knows colleagues at work that write very aggresively (and copying to the top management...), and when you meet them, everything runs smoothly. Sometimes is so easy to screw up everything just with a wrong adjective in an email...
    Besides, you can be critic with your boss by phone, but not in an email. :-)
    Good Interview, BTW
    Diego
  18. [snip]

    > Everybody knows colleagues at work that write very aggresively (and copying to the top management...), and when you meet them, everything runs smoothly. Sometimes is so easy to screw up everything just with a wrong adjective in an email...

    [snip]

    You're 100% right. This is very often a cause of miscommunication which escalates in unnecessary problems. Whenever someone starts working for the first time with someone else, we always try to set up a face to face meeting (travel). We've found that everything thereafter works smoothly. Whenever we have have not done this, it was much more difficult.

    -Vincent
  19. As vincent mentioned it is a bigger problem when you are working between time zones that do not have an overlap . Eg California and India.

    The following practices have made my life a bit better (I certainly dont imply normal).

    1. Schedule a Meeting involving (CHAT / Phone and / Netmeeting) daily at an odd hour for atleast 1/2 hour. Cant avoid the odd hour because there is no overlap.
    2. Prepare for this meeting in advance everyday and do not prolong discussions on a topic for more than 5-10 minutes. I mean do not brain storm on the call.
    3. All Brainstorming and discussions should be done via Text (Email/ Wiki/ message boards)
    4. have a code of conduct for posting messages on various internal message based forums. (like PM issues / Architecture / Business requirements).
    5. Learn from the way people communicate on other open source projects like hibernate , etc
  20. my experiences[ Go to top ]

    for some thoughts on offshore development

    http://dclab.blogspot.com

    Cheers
  21. Communication, communication!!![ Go to top ]

    We found a lot of the countries east of Europe (as far as India) will often delay their day to coincide with their parent company. I think there's a greater problem in the US due simply to the fact that they’re isolated in a thin slice of time zones.

    The key is constant and regular communication with continuous integration; they need to get used to a quick response from an ICQ message whether you're downstairs or 2000 miles away. When they check something in that breaks the build everyone needs to know within minutes, preferably seconds. Working long hours is often needed to cover the larger gaps though, i.e. West Coast US from Europe.

    Anyway, you guys in the US can stop worrying about outsourcing; the US$ is becoming so week that you won't be able to afford places like India, China etc. They're going to start re-outsourcing the work we Europeans give them back to the US to save money. :-)

    -John-
  22. Communication, communication!!![ Go to top ]

    John Davies: We found a lot of the countries east of Europe (as far as India) will often delay their day to coincide with their parent company. I think there's a greater problem in the US due simply to the fact that they’re isolated in a thin slice of time zones.

    I always thought that isolation was measured as the number of time zones away from New York City you find yourself.

    John Davies: Anyway, you guys in the US can stop worrying about outsourcing; the US$ is becoming so week that you won't be able to afford places like India, China etc. They're going to start re-outsourcing the work we Europeans give them back to the US to save money. :-)

    When you guys figure out how to combine the hot and cold water faucets into one, then we'll start worrying :)).

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  23. Communication, communication!!![ Go to top ]

    "When you guys figure out how to combine the hot and cold water faucets into one, then we'll start worrying :))."

    You mean you have hot water now ? :))

                    Yann
  24. Communication, communication!!![ Go to top ]

    Cameron: I always thought that isolation was measured as the number of time zones away from New York City you find yourself.

    So Bogata isn't isolated but London is? :-) The point was that you're a long way from most of the "usual" outsourcing destinations.

    I've no idea why you'd want water coming out of your faucets, we use taps. Most of the double tap systems were put in while you guys were still burning witches, I've not seen one for decades.

    :-)

    Peace to you too!

    -John-
  25. Communication, communication!!![ Go to top ]

    When you guys figure out how to combine the hot and cold water faucets into one, then we'll start worrying :)).


    Do worry, it is coming. I half overheard a news item that the new building code will require new bathrooms to have combined taps so as to avoid scalding. Wusses.

    The change is probably a consequence of Princess Margaret seriously scalding her feet half a decade ago.
  26. RAD and ODC[ Go to top ]

    Some ODC's usually adopt what they call 'RAD'. We usually don't generate code ( like MDA ) or do anything special. We take the easy way out 8-\ by spending 24 hours in the office and delivering something very rapidly. There is no design
    or proper architecture work done. Bugs crawl all over us later on and again we
    deal with that by living in the office.
             
     We started looking at RUP. Can't RUP be agile enough for ODC's ?
  27. Well these theories are floating since some time.
    Where they become effective is one demonstrated success story. In my experience
    it is important for professionals to apply apt commansence and customize these
    practices to suite the solution/scenario.
    I have seen couple of products where architect/leads applied agile mechanics
    to just apply them purpose and they failed.
    One needs to understand, customize, run a proof of concept then apply.

    Hari.
  28. Agile and Rup and offshoring...[ Go to top ]

    I am not sure we should look at the traditional models and Agile as mutually exclusive.

    In my experience I have found the following to work in offshore development

    1. Try to really finalize and freeze the requirements in Inception and Elaboration phases and then manage the changes via Change Requests(small purchase orders).

    Also , Document every small little requirement (stuff like button placement , Text formatting , etc)

    This is probably the traditional approach of doing things but I think it works in context with offshore development . Generally the offshore company is doing a Fixed Bid project and if you do not have signed confirmed requirements (documented to the level to a very detailed level) you are invariably going to run into conflicts.

    2. Some of the practices from agile are like to gospel to offshore development. "Continuous Intigration" . The importance of this I think is more in offshore development then in one location because the intigration solves to communication problem to some extent.

    3. "Continuos Feedback" . "Continuous Intigration" leads to continuous feedback and hence faster turn around cycles.
  29. Hello All,
    There is a yahoo group to share our experiences,tips, tricks and other points to improve Offshore Development Process.

    Please visit http://groups.yahoo.com/group/offshoredevelopment/

    Thanks

    -Swarraj.