One topic that often comes up with relationship to outsourcing software development projects is the use of agile methodologies. Having run a number of projects using agile methodologies with offshore (nearshore) partners I found that some of the classic principles do not work as well, for example XP’s “pair programming” and “moving people around” need to be taken with a grain of salt / adjusted with consideration of the lack of collocation.
Of course when it comes to agile development you need to start with agile evangelists’ take on the subject. Martin Fowler in what is now a classic article Using an Agile Software Process with Offshore Development covers 14 major lessons learned:
1. Use Continuous Integration to Avoid Integration Headaches
2. Have Each Site Send Ambassadors to the Other Sites
3. Use Contact Visits to build trust
4. Don’t Underestimate the Culture Change
5. Use wikis to contain common information
6. Use Test Scripts to Help Understand the Requirements
7. Use Regular Builds to Get Feedback on Functionality
8. Use Regular Short Status Meetings
9. Use Short Iterations
10. Use an Iteration Planning Meeting that’s Tailored for Remote Sites
11. When Moving a Code Base, Bug Fixing Makes a Good Start
12. Separate teams by functionality not activity
13. Expect to need more documents.
14. Get multiple communication modes working early
That list presents a great set of guidelines, and none of them are in the conflict with foundational principals of agile development. Some of them are unfortunately in a conflict with realities you might be facing on your project.
Let me start with items # 2 & 3. That is an absolutely correct way to improve communications – make the offshore as onshore as possible by swapping people, putting semi-permanent representatives on both sides of the ocean, etc. The problem with it is that many companies, especially smaller ones can not afford this approach. Bringing and offshore person on-site roughly brings his/her rate to what you would pay a local resource and for any considerable length of assignment is likely to cost even more than local resource. Sending your local resource offshore increases the cost substantially. Personal life of ambassadors is likely to be affected not necessarily in a positive way. To minimize the impact you might consider younger ambassadors however a lack of experience may defeat the purpose. Once again, I can not agree more with both techniques yet the chances are you would have to compromise on those and thus creating inevitable negative impact on the project.
# 4. To some degree this section plays down an obstacle that could be an agile showstopper. Martin Fowler presents a few interesting examples of cultural challenges that his team successfully overcame. You might have not as much success with it, especially when working with a third party provider rather than captive resources. Try “anti-authority attitude” with any top tier vendors in India, see how far you get – and do please let me know. Also, there is much to be said about forcing foreign culture onto people who will have to stay in the society that doesn’t support it.
There are of course many others cultural challenges that deserve a serious discussion; let me just touch on one: some people call it “having Agile in DNA”; some call it “agile aptitude”. That would be a topic for a very long discussion; for now I will cut it very short: some teams are just not made for agile; and that is a cross-cultural phenomena. The culture puts its additional imprint on the issue with deeply embedded cultural traits such as conflict avoidance, hierarchical structure, meaning of respect, etc. you often find offshore. Unless you have the luxury of building your own team you would need to asses the team’s ability to go agile and your ability to guide it thorough. In some cases you will find that being practically impossible. If ignored or not handled properly subtle sabotage will find its way to the surface through malicious compliance and will bring your project to a memorable fiasco.
# 9: Short iterations have a great positive impact on the project and alas high overhead as well which exacerbated by offshore communication challenges, time difference, logistics, etc. could be unbearable. In my experience two week iterations presented a reasonable minimum.
#12 & 13 get us into a line of fire of the holly war between agile and waterfall :) And in my opinion that is as productive discussion as the “mind over matter” (by the way the later one has been solved: “if you don’t mind it doesn’t matter”). This is not an argument anyone could ever win, there is a place for agile there is a place for waterfall, and everything in between. Pick the best tool for the job, adjust your methodology to accommodate for organizational requirements, environment and team at hand… of course “If the only tool you have is a hammer, you tend to treat everything as if it were a nail” [A. Maslow]
I think it’s enough of picking on the celebrity, time for a couple observations of my own:
Minimize the time gap. You can find many blogs and articles that talk about the time difference as an advantage, what a joke! 11.5 hrs time difference with India can easily result in 48 (business!) hours delay in resolution of urgent issues. If agile is your chosen path consider minimizing that gap; your best bet could be a nearshore offering, or farshore partners who understand the value of team overlap. Some of my favorite vendors take this issue on with a vengeance starting work hours for their employees at noon local time; interestingly enough that gives them some add on benefits such as less challenging commute.
Pick only engineers with fluent English. That one seems like a no-brainer yet you will find a lot of push against it if you deal with pretty much any geography outside India. The meaning of “all our engineers read and write technical documentation in English” translates from Vendorian (the language vendors speak) as “some of our engineers went through English boot camp when in college). While that could be a manageable obstacle for teams operating as a black box or in a well managed waterfall that will be a showstopper for a mixed team agile project.
Select developers with approximately the same skill level with exception of very few on a high and a low end; the ranking for those exceptions must be clearly understood and communicated across the team. That one cuts deep in the heart of some agile practices and beliefs so I have to put a couple thoughts here:
In software development all engineers are equal and some are more equal… The difference in productivity and quality of code for strong developer and average one could be tenfold, expecting them to work together is like expecting turbocharged Porsche and limping horse powered carriage travel together in an autobahn. If you build your team with the best and the brightest chances are they could be equal even if their experience is at different level: a bright engineer will have no problems stepping aside in a face of reason or experience. When freedom of expression is given to an average or a mediocre contributor on team that also has high quality developers the result is predictable – it’s either beat him into pulp or produce code at average or mediocre level.
There are many other negative trends that naturally develop in teams with wild mix of skill levels – cherry picking, slavery, slacking off – just to name a few. By no means I am advocating for arbitrary hierarchy though… In my experience the best agile teams are formed by like-mind professionals of approximately same level of skills gathered around a top notch technical leader.
Adding offshore spin on the requirement to keep developers at approximately the same skill level adds a huge challenge to the team building process, especially in hierarchical societies or/and organizations.
Build a team. Easier said than done, and that’s why it is my favorite craft. Building teams with offshore components elevates the complexity of the task to a completely new level. When it comes to agile development building a team from a group of people working on the same project makes all the difference; the difference so profound that it feels like magic. The good news is that you do not need to graduate from Hogwarts to be successful at building balanced teams that perform well on agile projects. OK, this topic requires much more than just a couple paragraphs or a few posts, maybe a very active stand-alone blog can give the topic the justice it deserves… For now let me just mention my formula for success :)
Establish solid project management. A dedicated PM is an absolutely critical role on an agile project of a decent size. This role becomes twice as important when the team is not collocated and another tenfold if the team spans countries. Strong s/w PMs are a very scarce commodity though. It takes solid technical knowledge, superb PM skills and personality match, considering limited pay rate and unlimited challenges – it’s no surprise they are so difficult to find. By the way, when it comes to agile projects I would take certified PMP and get him/her to learn SCRUM (or whatever the methodology is) over SCRUM master in 4 out of 5 cases. Not sure whether I am jaded or just biased. Having interviewed hundreds PM through my career that so far has been my experience.
Continuously improve the process. There are many techniques that will help you to do so, iteration retrospectives is one of the easiest ones. My teams use round table discussion approach with everyone presenting keeps and tries that are captured and tracked by the PM. Tracking is essential as even great ideas tend to get lost unless there is a driving force behind it.
And the last one for now: do not compromise on tools. Agile teams have all too common gravitation towards open source. That’s commendable yet needs to be taken with caution. More so, when it comes to development tools open source doesn’t always mean the best or even “good enough”. Some tools supported by gainfully employed professionals offer impressive value and are substantially more reliable than those supported by the community. For example my team after numerous attempts to work around some limitations of CruiseControl settled on Bamboo with notable impact on productivity. Same goes for many other tools (CI, Testing, Code Review, Wiki, etc.), so do not compromise on them, pick the best you can afford.
Well, with all those caveats and warnings you might think that agile and offshore do not mix. I would not say so, while running agile projects with distributed teams is not a trivial exercise it could be productive, efficient and a lot of fun. Given the right opportunity I would do it a heartbeat.