Return to site

Effective nearshoring

lesson learnt: communication

I have worked for 4 last years in offshoring company, which provides software development services. It has been a period of great experiences in offshoring model, which currently abounds in successful collaboration with the customer from the western European country. Nevertheless, that cooperation hasn’t been so successful since the very beginning. My teams and I had to operate with the great effort to build effective processes and the customer’s trust.

Therefore, in series which is started by this post, I will try to familiarise you with different improvements and processes that we implemented to enhance cooperation and to make the customer happy. With this post I will try to present the essence of communication in terms of the teams collaborating remotely.

At the very beginning our collaboration was not so smooth as the last several months. Four years ago we started work on one of the projects. Then the main goal was to support delivery which was upcoming in great strides. The workload was estimated for few months, however the team needed much more time to get this done.

It was the time when communication tools used in the project were limited only to specifications, which were not necessarily of a good quality, same as the long running email chains. Being bounded only to these streams of domain knowledge was really hard for team members who appreciated agile approach and interactions over processes. This old-fashioned way of cooperation became problematic due to long feedback loop. Sometimes the team waited for customer’s contribution even a few months. From the team perspective it was really demotivating furthermore the quality could not be as good as we and the client expected. Likewise, even seemingly trivial matters took us too much effort and time to establish and then implement solution.

On the team though, collaboration and knowledge transfer are extremely important so that they can collectively work as one mind.

Fortunately we got a chance to enrich the collaboration model. We were invited to cooperation on the brand new project of this customer. New venture from scratch gave us fresh look and occasion to betterment.

work onshore

First step which we have done, I was delegated to operate with customer’s technical staff and implement the proof of concept for product which they were going to develop. I spent 2 months on place in their headquarters, working on solution in brand new technology with unknown team. On the one hand it was great experience for me and the time when I learnt a lot, but what is important, during this time I was able to understand company culture, expectationsand even build foundations for future partnership.

I believe it is important to get onshore experience, to understand other company’s processes, expectations or culture before you become offshore partner. Looking back, I would say that it would be much better if I had stayed there for a longer period of time.

process known for all parts
As a next matter to deal with I suggest to get all stakeholders familiar with process. It does not have to be the final definition of workflows and courses, we are agile and according to adaptive approach we should adjust operations to project’s context over time. However, it is reasonable either to gather regular feedback about processes, or share information about eventual changes and improvements. All parties should get detailed knowledge about planning, prioritization, backlog management, progress reporting, delivery procedures and stick to particular sets of agreed rules which control them.
daily and weekly meetings rhythm

It is often the matter of attitude that external team is not keen on participating in remote meetings. This bearing sometimes relates either to lack of skills in foreign language, conviction that ‘mine’ tasks are more important or the issue of personality type – introverts (applicable mainly to programming geeks, but it is not a rule).

Thus we prepared scheduled rhythm of daily and weekly meetings. Make this timetable a part of governance procedure. All parties should accept it since the beginning of collaboration. By letting outlined players (sometimes even all the team members) meet every week for about an hour to depict results of last sprint, refine backlog, examine issues/improvements repository etc., seems to solve communication problems itself.

proficient communication roles

Meetings defined in calendar are only the first step in the walk for the efficient communication and customer need’s understanding. Afterwards we have to delegate representatives to participate in the exact meetings and define communication responsibilities.

If there is a need (kicking off work on a new module, product) get a chance to set up live workshops. It is always good to meet face to face from time to time. Meeting in person builds your knowledge of each other’s characteristics and communication style.  Afterwards remote communications are much better and as a result misconceptions don’t occur as often.

clear guidelines on how to build backlog

The Product Owner as a role in charge of requirements, acceptance criteria, prioritization is in effect significant. It is crucial to optimize the communication between development team and PO. Thus it is valuable to define the set of guidelines according to which Product Owner communicates to the team the requirements and priorities. In this case either user stories, set of acceptance criteria or user story mapping (tool for planning) are useful instruments and should be standard practice in collaboration.

To scale out the Product Owners functional knowledge is worth taking to support their activities. Therefore sounds reasonable to delegate one of the team members to closely collaborate with Product Owner and get detail knowledge about requirements and criteria of acceptance. This is typically Quality Assurance engineer who works on test scenarios. It is even more important when Product Owner works remotely from another location.

If you have opportunity to enhance your “cross-functional team” by the User Experience expert, do it. In our case it helps a lot with user stories refinement and in consequence in meeting customer expectation.  What is interesting, the involved UX expert became a natural candidate to take the Product Owner Proxy role in future ventures. When she was working on detailed UX analysis, she delved into functional and usage details which allow gathering domain knowledge. Mixing this with predispositions to be a Product Owner gave us excellent results.

We have taken that chance of getting better understanding of business and the Product Owner Proxy institution was set up internally on our side. This movement improved communication and cooperation on line PO – development team. Both feedback loop and transfer of requirements description became more effective.

robust project tracking tool

In large projects where team is located in different places, it sounds reasonable to organize central point for contact. Site, where the team can build knowledge base, exchange messages, analyze progress of deliverables from another team etc. It seems natural that project tracking tool (e.g. JIRA, Trello) is one of that kind of places. Enhanced by project wiki and blog can be a very efficient gear in fight with communication issues.

The teams should invest time to organize this kind of project tooling – define common usage rules and attitude to work with it in the daily habit. It is important to avoid duplications and plenty of tools for the same purposes (project trackers, code repositories) used by different teams. Which promotes hiding informations.

progress reporting

For all customers the important thing is to know where we are with the software development at a time. It is common situation that offshore partners complain about lack of progress visibility. This blocks them from making proper forecast of budget and commit to particular timetable with the end customer or user. On the other hand, situation where offshoring supplier is not aware about milestones which client undertook is also risky for project goals.

Therefore from the very beginning  it is essential to set up regular checkpoints (demo, last sprint metrics or backlog review meetings) and use proper tooling to allow customer easily understand depicted reports. Concerning instruments, really valuable could be features of JIRA, Confluence, Trello and other project tracking tools.

Wrap up
“Assumptions are the termites of relationships.” Henry Winkler

Don’t allow that your team work is based on too many assumptions. It is applicable either for understanding of requirements, planning, customer expectations or feedback on quality of work. Build communications structures that will be understood by all parts and used to dispel doubts.

Taking care of individuals and interactions is obligatory for software delivery effectiveness. Thus when is either need or opportunity, meet your customer’s team face to face. Don’t be afraid to work onshore.

Certainly, even if some of these practices are applied, still building relations depends on representatives communication and negotiation skills. Nonetheless, I believe the heavy and high-quality work of the delivery team can make wonders.

If you come across communication issues with your partner/ with your supplier/ in your agile organization, drop me a line and I will get back to you.

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly