The topic of cultural differences has always interested me and I found interesting the work of Geert Hofstede who has systematized the roots of cultural differences into five dimensions. I was particularly intrigued to see that ethnic Latvians are more like Scandinavians and that Latvia culturally belongs to the Northern Europe and not Eastern Europe. At the same time, talking about culture in a work environment has always been difficult. Culture is such a “fluffy” topic, and it is so easy to blame culture. Every now and then I hear about software engineers working in distributed projects that cultural fit is a challenge, that “they” have different values, that “we” do things differently. And, to be honest, transferring the theories from the books into practical recommendations is not an easy task! The question of what does it mean in practice to have different cultures among software engineers is not straightforward. Besides, generalizing people behavior in a particular country is dangerous, since along with the national culture, there is regional, organizational, team and finally individual culture and individual differences ultimately dominate the national ones! Yet, a while ago I received a task to develop a cross-cultural awareness course for two collaboration companies from Sweden and India. Continue reading
My current research interests are related to understanding the scalability of agile principles in large-scale distributed projects. The core principles we study are autonomy, self-management and self-governance. In April this year we have started a new research project looking into team autonomy in multi-team multi-site projects. The first study conducted indicates that teams receive different degree of freedom to decide on their ways of working and who can be on the team, while the decisions regarding the overall direction are taken by the line management without involving the teams. One of the studied companies strives for alignment, standardizes the “best practices” across teams, while the other delegates such decisions and cross-team coordination to so called communities formed by the teams themselves.
How much can your teams decide? What is aligned and what is not? Care to share your experience – comment here or contact me directly via email.
Finally, I remembered the almost forgotten work that we have done together with Nils Brede Moe and Pär Ågerfalk by putting together a collection of case studies on agile principles in distributed projects in the book – Agility across time and space published by Springer in 2010. Our work still seems useful and applicable, and is not doing that bad statistically 🙂
A couple of years have passed since we started quantifying the bottom-line costs of offshoring. I must say that doing it right is a very hard work. I am proud to share the next data point – a Swedish company (anonymously referred to as SwedCo) that develops complex software intensive systems and has on-boarded Indian developers on a 15+ years old legacy product. Our task was to obtain as objective performance and cost evidence as possible. In contrast to the DutchCo case, we approached the learning curve measurement differently. We have studied all customer-specific features completed by the Indian teams during their first two years of work, and compared them with a number of similar tasks completed by the mature teams from Europe and USA.
First we measured performance in terms of the hours per complexity point. We used the real effort per task from the archives. We normalized it by a fictitious measure of complexity points, which represented as objective complexity of a task as possible, and were estimated by the architects involved in designing the features. Notably, during the estimation they did not consider who completed a task.
We have traced a number of cost drivers that were not present in the work of mature teams, such as the travel costs, knowledge transfer costs, costs of control, support costs, rescue costs (fire-fighting performed by the architects) etc. Some of these costs were unforeseen by SwedCo. Two types of costs were then calculated:
- Hourly costs as the salary-based hourly rates + the extra costs,
- Bottom-line costs per 100 complexity points as the hourly costs divided by the productivity.
Due to confidentiality we were unable to disclose the real costs, and all our costs are expressed in Galleons, a fictitious currency. On the bright side, we have been lucky to get access to performance data from the inception of the Indian teams and cover their first two years of work.
What did we find?
All cost drivers that we have identified could be directly or at least strongly attributed to three categories:
- the transfer of work or the onboarding process,
- working on a distance,
- immaturity of the offshore site.
When the of extra costs were added, the hourly costs have increased several times if comparing with the salary rates. The initial 4 time difference in the salary costs (100 galleons/h in India versus 400 galleons/h in Sweden) turned into a mere different of 35% in favor of the Indian teams on average after two years.
The performance gaps between the mature sites and the immature site led to an even higher difference. As a result, two years after on-boarding of the offshore teams, the bottom-line costs of the mature teams in high-cost locations continue to be 40% “cheaper” despite the big salary differences.
Guess what is the main factor?
We have found that performance did not improve primarily because of attrition. Similarly to DutchCo, we have found that in order to employ 50+ developers, SwedCo have recruited the double amount of developers and lost half of them for various reasons, including internal promotions.
Finally, we have modeled a number of development scenarios for the performance and the costs, however the most positive hypothetical scenario, in which SwedCo could break even, is very unrealistic.
In just a few weeks I will revisit DutchCo and calculate their bottom-line costs using the performance data. They have implemented a number of improvements. Let’s see how it looks now. A post regarding the DutchCo case will be published. Meanwhile, if you would like me to calculate the bottom-line costs in your offshoring collaborations, contact me via darja.smite AT bth.se
In the new issue of IEEE Software (Nov/Dec 2016) Ricardo Britto, Lars-Ola Damm and I share a story of architects working with remote teams at Ericsson. We have followed a case of a large-scale monolithic legacy product development trying to understand how new teams are onboarded and improving over time, and whether the company will be able to step away from the centralized architecting towards more trendy approaches to evolving the design of the system.
In our study, we have found that architects play a major role in guarding the system’s integrity and evolvability, and mentoring the new remote teams. They review the code, they propose the design of the work items, they even suggest code improvements to speed up the progress. The importance of architects’ support is naturally higher when teams are immature, and decreases over time. In our study, we came up with the factor 4,5x.
Our findings have one major implication. When a company wishes to have flexibility in deciding where the system is developed, and scales up and down in different remote locations, we believe it is impossible to step away from the centralization of the architectural decisions and control. And this is especially true in complex legacy systems, in which it takes years to accumulate enough knowledge to become productive and independent.
An opinion article has appeared in Dagens Industri as a response to the recently trending debate of whether or not to move more R&D work to lower cost locations. What follows is a short overview of the motivation behind the article.
What is the key message of the article?
Offshoring does not necessarily lead to cost-savings. Moving complex knowledge-intensive work often leads to a number of unwanted outcomes – decrease in quality, productivity, and speed‐to-market. Therefore, the salary comparisons become inadequate, since the companies receive different value for money.
What motivated me to write the opinion article?
The article is a response to the recent coverage of layoffs at Ericsson in the Swedish press and the coverage of offshoring practices in the Norwegian press. It is written to raise the public awareness of the research evidence regarding the topic, and to counterforce the rumors, and offshoring propaganda by those having a vested interest.
Who am I to have an opinion about offshoring?
I am a professor in software engineering at Blekinge Institute of Technology in Sweden and a part-time research scientist at SINTEF ICT in Norway. Before my academic career I have spent 6 years working in industry in Latvia, as a software developer, a system analyst and a project manager. I have received my PhD in 2007 from the University of Latvia. During my doctoral studies and ever after I have dedicatedly focused on understanding the impact of globalization and offshoring for software companies. I have conducted research for a number of international companies such as Ericsson, ABB, Emerson Process Management, and HCL. I have visited software companies in China, Latvia, the Netherlands, Norway and Russia, and have talked to developers from India, Poland and Ukraine.
What is the evidence behind the discussed experiences?
The evidence is gathered through a number of empirical and non-empirical research studies:
- D. Šmite and R. van Solingen “What’s the real hourly rate of offshoring?”, IEEE Software, 2016, 33(5): 60-70.
- R. Britto, D. Šmite and L.-O. Damm, “Software Architects in Large-Scale Distributed Projects: An Ericsson Case Study” to appear in the IEEE Software special issue on Software Architect’s Role in the Digital Age, November/December, 2016
- D. Šmite, F. Calefato, C. Wohlin “Cost-Savings in Global Software Engineering: Where’s the Evidence?”, in IEEE Software, 2015, 32(4): 26-32
- N. B. Moe, D. Šmite, G. K. Hanssen and H. Barney, “From offshore outsourcing to insourcing and partnerships: four failed outsourcing attempts”, In: the Journal of Empirical Software Engineering, 2014, 19(5): 1225-1258
- R. Jabangwe, K. Petersen, and D. Šmite, “Visualization of Defect Inflow and Resolution Cycles: Before, During and After Transfer”, In: Proceedings of the APSEC conference, 2013, pp. 289-298
- R. Jabangwe, D.Šmite “An Exploratory Study of Software Evolution and Quality: Before, During and After a Transfer”, In proceedings of the IEEE International Conference on Global Software Engineering (ICGSE), 2012, pp. 41-50
Which companies does the evidence come from?
The majority of the findings discussed in the article are based on the experience accumulated from a number of different cases, and are not traceable to the actual products, sites and companies. The hourly-cost comparison that demonstrated that Indian developers after 5 years of collaboration are still more expensive on average than Dutch developers (link) is based on an research study conducted in a small Dutch company that decided to remain anonymous.
Am I against offshoring?
No, I am not. My goal, in fact, is not to take sides. My goal is to show the evidence and answer questions that companies might have, by means of research investigations. My expert opinion is that offshoring does not lead to cost savings in companies doing large-scale complex software development. I have no evidence on e.g. web page outsourcing. It is also my expert opinion that there are other good reasons for software companies to globalize and have local presence around the world, e.g. where the customers reside in order to better understand the market and the users.
How can public readers access the research articles?
The research articles are available upon request.
When comparing the hourly costs of software engineers in high cost versus low cost countries, one may wonder whether there is any good reason to develop software in Europe at all. One fundamental problem with such comparisons is an assumption that companies pay for working hours. Well, it’s important to get the value for money, isn’t it? What constitutes value in this context is timely delivery of working software that satisfies requirements set by the customer or the company that outsources their development to an offshore vendor.
When we started to look into software transfers, relocation of ongoing software development or maintenance from one location to another, often offshore, it was a general impression of the middle management that the upper management would be happy if the transfer would happen over night and have no impact on performance, deadlines, or customers. In other words, people who have previously developed the product would stop working in the project one day, and the new people will take over the following day.