Streamline communication accross the pond

That’s it! I’m going to rename this blog ;-). It’s all about communication again.

Since I started to work as an Offshore Manager almost 3 years ago I became sort of a “communications hub”. Team members in Ukraine got used to communicating to other development managers and team members in US through me. While it made sense in few occasions we didn’t do much about it, especially because I was a development manager for majority of the features developed offshore. Bad habits are hard to break, so this went on for quite some time, until we moved to Agile. With me coaching all the Agile teams that came on board I still could be the communications hub, but I decided to seize the opportunity and change this behavior across the teams. Now I encourage all team members to communicate directly to their Scrum Masters, Product Owners and peer team members using any communication channels available. With Skype, cameras and headsets the bar is so low, that talking to someone across the pond is almost easier than walking to another room on the same floor.

In my capacity as an Offshore Manager I still help identifying inefficiencies across teams and manage core as well as “out-of-band” projects, but now my team members in Ukraine are more self-sufficient and don’t depend on me for communication with their peers in US. This allows for more time focusing on scaling Agile and coaching multiple Agile teams.
While this transformation is not easy as it requires certain comfort level from both sides of the ocean I see how Agile being a catalyst by fostering this behavior. There is just no other way to communicate if we want to succeed with Agile, so everyone is vested in making it work.

When Offshore meets Agile

This post belongs in both of my blogs “Leading Agile Transformation” and “Succeeding with Offshore Management”, so I’ll publish it in both…

When companies look at Agile the question of location often comes up: people are afraid to implement Agile with offshore teams due to the distributed nature of the teams. Of course it’s great when you have face-to-face communication, but I see no problem with implementation of Agile in distributed environment (ok, maybe some challenges).

There was a research done on the subject of communication in different office settings, and what they found is that best communication happens when people are sitting in the same area or in adjacent cubicles. Next best setup is an offshore model and the worst setup is when people are located in the same building but not in adjacent areas. The difference in communication efficiency was significant between 2^nd and 3^rd categories, but insignificant between 1^st and 2^nd. One of the reasons for these findings could be that people in the 3rd category think they are collocated and do not need to invest in improving communication channels and communication efficiency. On the other hand, folks in distributed setting are well aware of the challenges of communication and are investing a lot of effort in constant improvements.

Agile fosters frequent communication and helps distributed teams to advance to the next level of efficiency. Yes, there are challenges that are exacerbated with Agile: more communication requires more discipline and sometimes changing the ways we communicate and may require additional tools to support it. This is not different from any other problem that Agile helps to put a spot light on and that requires resolution. Agile will emphasize what we as an organization need to focus on to make sure required communication levels are met.

One thing we’ve been struggling with before was choosing the right timing for onsite visits: the environment was pretty chaotic and it was difficult to plan for a visit and to tie it to a certain event (planning/design review, etc). With clarity of SCRUM it’s obvious how we can leverage the framework to plan for visits: Release/Iteration planning and Demo sessions are a natural fit for this.

As part of our Agile transformation I’m making sure to have not only Agile enthusiasts on  the other side of the ocean, but someone in coaching capacity to augment my efforts on site and help teams when I’m not available due to time difference or any other reason.

Tomorrow never dies (or will offshore development survive?)

"It's hard to predict, especially the future".
--Niels Bohr.

First value proposition of the offshore software development was saving [a lot of] money by employing software engineers from developing countries at much lower rates. As Developing countries’ economies grow at much faster rate and those gaps are going to be eliminated in the next 5-10 years, will offshore development still survive?

For some of the countries it’s already the case. Israel is one of the major offshore destinations and the cost of hiring an engineer there are not much lower than hiring an engineer in US. Do companies stop doing business with Israel? Not really. Well, many companies are still looking at the cost as a major factor and Israel is definitely loosing it’s offshore development market share, but I believe that as the rate gaps get closed offshore providers will have new value proposition that will keep them in business.

Many companies got burnt by letting someone else to perform one or several software development functions at a lower costs. Through much pain these companies understood that offshore software development has many success factors and these companies have changed their approach. These companies have realized that time zone difference, cultural differences and lack of face-to-face contact in virtual and distributed environments require great deal of management to succeed.

At the same time, offshore providers have also realized that they cannot get requirements, deliver software and call it for a day. In fact I remember an Information Week article few years back talking about Indian offshore providers and their inability to provide innovation. I do not believe that Indian engineers cannot provide innovation, I think that offshore providers have not looked at innovation as a value proposition, and frankly, US companies have not “put this line item in the contract”.

I believe that while many offshore providers might be out of business in the long run, the ones that will survive will have a game changing value proposition that most likely will be around innovation. The other alternative for those providers is changing the business model completely and using great talent pool for spinning off some start-ups.

Beware: Economic Growth

When economy is on the rise it’s good for everyone (or at least it seems like it). Beware. With developing countries entering global economy the annual growth rate is much higher than in US, in good times that is. Fast growth contributes to many factors you should take into account when managing an offshore engagement.

Let’s take a offshore software development provider and will call it OffSoft Inc for the sake of example. In the recent years OffSoft Inc has expanded its reach to customers in North America and Europe and fast growth in customers warranted 30% growth in workforce. With such a massive growth, company found itself with non-adequate structure and upper management decided to go through major reorganization to accommodate this growth rate. New units were created and new management levels were added. Now assume you have a team of 30 folks including a project manager, technical leads and senior engineers. Who will be first candidates for promotion that would take newly created management positions – they are…. So here you are facing situation where some of your most brilliant team members move on with their career, directly impacting your team’s productivity. Don’t get me wrong – I’m glad folks have great career opportunities, but nevertheless it’s a risk that has to be managed. One trend that related to fast growth and is specific to Russia and Eastern Europe - deficit of specialists on all levels from junior engineer to senior management. This is the opposite from India, where despite high growth rate you can see a surplus in engineers and deficit in senior management levels. (This is taken from HBR article I came across in fall 2008. Now, with economic downturn the picture might have been changed). With economic growth slowing down I believe these deficits will be eliminated.

In Communication we Trust

Building trust is activity that never stops. Trust arises from strong relationships, and relationships need to be built, maintained and nurtured. Management literature mentions trust often, but no one really tells you what it is and how to “get it”… and I’m not about to do that either. I rather tell you what it means for me and how it works for me in managing offshore Engineering organization.
In the center of my relationship with my peers in Ukraine is information sharing and extensive communication. Of course there is the limit of what I can possibly share, and of course I do not share all the information with everyone, but I try to be as honest as I can in the communication and share the right information with right people. Honesty is very important factor here: if I decide to share information – I’ll be honest about it, and will not fabricate a story. Otherwise I won’t share the info at all… and when I don’t, I explain why I cannot share the info or cannot share it yet. Honesty from my side breeds honesty from their side and this allows for healthy dialog to take place. All this breeds transparency in relationships and breaks communication barriers leading to successful offshore engagement.
Another technique that helps me in trust building is emphasizing the expertise of the offshore team in certain area and make it visible to both local and remote teams. Offshore team needs to see that there is transparency in work assignment, which shows that we rely on every engineer the same for work to be done regardless of physical location. Delegating process improvements analysis and proposals is yet another successful technique. When we would like to make adjustments or improvements in how we work in certain area, we won’t just come up with the process and impose it on the offshore organization. On the contrary, we would ask their opinion, and in many cases will ask them to come up with the process. Brilliant folks as they are they usually come up with ideas that after some massaging get incorporated into our daily lives. Environment that this kind of relationship creates ends up causing offshore team to identify themselves more with our company and feel really part of the same organization.

Extended Teams

Many problems related to offshore development that are reported in the industry often being explained by culture difference, lack of communication, time zones etc. From what I’ve learned, many companies reporting such problems do not have optimal team structure. Popular models include complete outsourcing of engineering team or outsourcing of one function only (QA being very popular). To “protect” from failure, these companies often build in SLAs into contracts.

Popular as these models are, the outcome of such engagements is rarely optimal for both sides, with [yes – you’ve guessed it!] poor communication framework built into these models.
Alternative model with much more chances for success is what I call “Extended teams”. In this model, offshore teams are not silos, but actual extensions of the onsite teams. The idea is that from management point of view, the only difference is – location. This allows engineering management perform planning based on skills and availability and not location. Of course if you work with Indian offshore company, this will be much.. much more difficult due to the time difference, but in our case, working with a Ukrainian company the time difference proved to be a non issue in most cases.
Good communication is built into this model, as feature teams, including members from both sides of the ocean HAVE TO communicate often and effectively to produce good results. Now here is a caveat: for several years this was working for us and proved to be successful. As our organization is moving towards Agile product development we need to decide whether this mixed mode is the best approach or should we move towards collocation, building complete teams in one location to the degree possible. Moving to collocated teams in offshore location will actually improve the team members interaction and communication, but will require more oversight by onsite architects. It becomes more complicated when we consider shared resources available onsite only, but need to be part of Agile teams.

More update on that later on my Agile Transformation blog.

It's all about communication

When people are asked what the three most important success factors in offshore engagement success are, they may suggest answers like trust, face-to-face communication, onsite visits, contract negotiation, expectation setting etc. In my opinion the three most important are communication, communication and communication – everything else is a direct consequence of intensive, well nurtured communication strategy.


Good communication strategy considers offshore team’s culture and structure, it has such qualities as transparency and honesty and it helps build long lasting relationship based on trust. The whole idea is to minimize gaps between company’s core engineering team and the offshore team.

In following posts I’ll focus on different aspects of successful offshore engagement emphasizing the role of good communication practices.