At the GOTO conference (in Aarhus, Denmark) yesterday I attended a series of talks on the subject of Agile. The subject is always relevant, though I have to say, some of the talks were less than exciting. This should come as no surprise, after all, the talks are designed to be for everybody, and so the level of detail and case studies, are relatively low. This made me realize, today, that I learn a lot more, from going to talks on something I know little about, than to subjects I am well familiar with.
But what is a conference if not a chance to talk to your peers? So that is exactly what I’ve been doing. Sunday night was the first chance to do this, at the speakers dinner, and this led to me talking to a group of people from a company in Copenhagen, who were very satisfied with their sourcing company in Sri Lanka. A positive sourcing story? This immediately piqued my interest, as sourcing is usually a source of complain more than anyting else. Good news are welcome!
So after a few days discussing sourcing with various conference participants, I’ve heard about distibuted setups in various Companies. This is what I concluded is a good approach, to success with distributed teams and sourcing:
- the respect for the sourcing company and the individual employees has to be high (an architect actually commented: some of these developers in Sri Lanka are smarter than me, that’s just something I have to admit to myself when dealing with them)
- the time difference is not too big an obstacle (Sri Lanka sounds a lot further than the actual 4 1/2 hour time difference from Copenhagen)
- the developers from the sourcing Company in Sri Lanka are invited to Copenhagen from time to time, so the different departments can get to know each other
- the above action (visits to the HQ) leads to be the benefit of knowing the different personalities of the Sri Lankan developers – a key to having a productive relationship with them
- have 1-1s early on explaining what you expect of the developer. This may include obvious things like, let me know if I am wrong, even though I am your boss. Or admit your mistakes – how else can we fix them.
- don’t break every task down, and explain exactly what you want to each developer. If this is necessary, you have neither the trust or the developer you need.
- do code reviews and give feedback, that explains what sort of detail and quality you expect. I actually heard of sourcing developers delivering work that was too good; i.e. the work was made with the intent of demonstrating the skill of the developer, rather than solving the task at a reasonable rate and way
This may sound very basic (apart from the expense of flying people in from another continent), but is of course harder than it sounds. Traditional reports will tell you, that the respect the developer pays to his employer is too high, and does not permit him to critisize an idea or assignment. From what I hear, this is still an obstacle, but a good developer will know he or she is a good developer, so if the relationship is professional, you should be able to work towards a better, trusting relationship.
So basically: Treat your sourcing employee with respect, and you’re on your way to a great working relationship, like you would have with any other employee.
This may sound obvious to you. If so, good for you. You’re on the right track to sourcing. Also - let me know if I can add anything else to the above list.
Mads Troels Hansen covered ‘Do’s and Don’ts for Distributed Scrum’ on Monday (his slides can be found here). His talk was quite extensive, covering a lot of patterns for working with distributed teams. I found myself thinking along the way, that we’re on the right track with sourcing in my company, but then he left us with a remark that floored me: Do distributed scrum for the right reasons.
I take the above to mean don’t do it to cut costs, do it because you value the skills of the sourced workforce. In my world, everybody is trying to cut costs where they can, because software development is an expensive and competitive business. I think every Company would prefer in-house developement to sourcing, so when they go for that solution, I think we can guess the reason. Which I guess is added value, in a roundabout way, from professional work at a lesser cost