Jon Last, Head of Delivery and Leon Doherty, Engagement Manager at NashTech
The offshore development model has become the optimal choice for organisations looking to cut down costs while maintaining quality and up to date service. Yet offshore models may not always be the right model for organisations; presenting time zone challenges, communication and immediate access problems. This article explores how NashTech operates to overcome common time zone challenges present in offshore partnerships leveraging our agile software development methodology.
The value and effectiveness of employing an offshore team for software development has become well accepted. With technology global and ubiquitous, it's rightly recognised that skill levels and expertise in developing code and crafting technology solutions is every bit as high in locations like Vietnam and India as it is in the Americas or Europe.
It can also be highly cost-effective. Using an offshore team in Southeast Asia will bring a client a significant cost saving compared to the rates charged in Eastern Europe, for example.
But one issue that is often raised, and that can be a real sticking point in clients' thought processes, is the question of time zone differences. India and Southeast Asia are anywhere from 4-8 hours ahead of Europe. This means that the only overlap during normal working hours is European morning/Asian late afternoon. Similar dynamics can arise between North America and South America. Can a complex software development project work under such conditions?
From our long experience at NashTech, with a 2,000-strong development team in Vietnam and 300 developers in India, the answer is a resounding 'yes' - although, naturally, there are caveats that we'll get onto later.
Essentially, it all comes down to planning and taking a highly structured approach - which might appear to fly in the face of Agile!
At NashTech, we deliver offshore software development projects using Agile Scrum, typically in two-week sprints. This starts with a sprint planning meeting at the beginning and ends with a demonstration and a retrospective meeting at the end, with daily standups throughout.
The key to success lies in our system of user story lifecycle management and refinement. Through this, we collaborate with the client to define user stories and place them into the Product backlog. These user stories are then refined through further discussion until the User Story meets an agreed Definition of Ready (DoR). Only User Stories that have achieved DoR are available for assignment to the sprint in Sprint Planning.
This means that when a sprint begins, the User Stories are very well understood from both a WHAT and a HOW perspective by the offshore team. And they have a full list of User Stories to develop - avoiding the doomsday scenario of having no work or insufficient work and having to wait until European morning to discuss alternative work with the client.
This approach is highly efficient and effective. We often find that the challenge is ensuring that the backlog of User Stories at DoR is sufficient for between 1-2 sprints ahead of the current sprint. We want to avoid having more than 2 sprints of work at DoR as that likely feels more like waterfall.
There are other ways in which the time zone difference can be leveraged to a positive effect. We have developed a system of 'baton passing' between our onshore Project Owner (the client owner of the WHAT) and the offshore Business Analyst or proxy Project Owner for the outlining, elaboration and review of future sprints. Effectively, it creates an extended working day - when one party is sleeping, the other is working and elaborating. The same system applies to User Story outlining and development - collaboration and baton passing back and forth between PO and BA turns time difference into an advantage, not a disadvantage - enabling us to get more done in less elapsed time.
Nevertheless, and as we have indicated, there are some circumstances in which the time zone difference model does not work as well.
This mainly applies to more chaotic environments where there is a high degree of unpredictability and changes multiple times per day. If it is not possible to identify work that is stable for an offshore team, we recommend that such a working environment is best supported by an onshore team working in the same time zone as the client to maximise the overlap of time for those chaotic and frequent discussions.
Kanban agile working (as opposed to Scrum) is a case in point. Because the Kanban approach is about working on a single task at a time until it is done, the timings and progress of a project are very uncertain. The time zone differential could create issues as a result. The structured, pre-planned methodology may begin to break down.
The right-sized offshore agile team approach requires discipline and planning. It demands commitment and professionalism. But it also creates a palpable rhythm and a drumbeat that is highly motivating and productive, both for our NashTech teams and our clients. In our global, 24/7 modern world, time differences can most certainly be managed. And the result can be done, faster, at the highest level of quality and value.
To learn more about client projects we have delivered using our agile software development methodology, read our success stories here.
To find out how we can work together to achieve your technology goals, click here.