Offshoring Agile When You Are a Startup

Working with an offshore partner becomes faster and cheaper as communication technologies continue to improve. It is possible to achieve agility with an offshore team as long as you understand the limitations. Although some of the principles from the agile manifesto are difficult to reconcile with offshoring, they can still be used as guidance to work effectively together.

Will Lord, former CTO and currently board adviser at EdPlace, spoke about offshoring agile at Agile Cambridge 2017. InfoQ is covering this conference with Q&As, summaries, and articles.

InfoQ interviewed Lord about finding a suitable offshoring partner, if the agile values and principles are suitable for offshoring, how they adopted agile and what they learned from offshoring agile as a startup, and when to use offshoring and when not to.

InfoQ: What made EdPlace decide to use offshore teams?

Will Lord: To begin with, it was a purely pragmatic choice. We’re an online education service for children aged 5-16 and our founders are non-technical. They needed to get a proof of concept up and running quickly and at low cost. Offshoring presented the best opportunity to do so. Since that time we’ve continually reviewed the processes we follow, the teams we work with and our technology needs and have always come back to using offshore development resources. For startups whose focus is more on experience and content and less on complex technology innovation, offshoring makes sense because there are few other options that are able to provide agility (in a business planning sense) along with value for money.

InfoQ: What did you do to find a suitable offshoring partner?

Lord: My previous answer makes offshoring sound like a no-brainer, but it’s a complex process that comes with its own overheads. I still think the overall costs should be considerably lower than building a team of your own, but you shouldn’t forget about the time it takes to identify and manage an offshore team. For us the identification process was probably the hardest part. When I started working at EdPlace I took over responsibility for an existing offshore team but soon found that we would need to switch suppliers if we wanted to move the product on. The original partner was based in India but we were open-minded about the location of the new team so we were casting our net pretty wide. When identifying potential partners, I found it useful to look at the three Cs: Cost, Culture and Capability. Cost is pretty obvious - some countries (notably India) continue to cost considerably less than local or nearshore development teams, even when you take into account management overheads, while others are becoming increasingly expensive. Estonia is a good example of a country with a big software development focus but whose prices are approaching parity with the UK or other Western European countries. Capability simply means understanding whether the team has the skills and focus to deliver what you need from them. That might mean coverage of a particular technology or a specific domain. Finally, and most importantly, you need to think about culture. There is language of course, but also attitudes – towards clients, towards their staff, towards technology – that will have a significant bearing on whether you can work with the team long-term. Being agile means building strong interpersonal relationships so you need to know that there’s some "chemistry".
 
I spent a couple of months doing desk based research into potential partners – looking for recommendations, seeing who was winning awards, meeting local representatives and having initial conversations. I then sent out a request for proposals (RFP) to a shortlist. Finally (having ended up shortlisting only companies in India), I went out to meet the teams in person. I think this is absolutely critical for all but the smallest project. It’s easy enough to make a good impression over the phone or through some nice marketing materials but you really need to see how things really are in order to make a sound judgement. I saw one company who was basically working out of a semi-derelict building and I immediately knew that they weren’t going to be a good fit for us. I eventually found a team whose culture was a good match for ours, who had strong capabilities and had robust technology leadership in place. The key to finding that team was really building a deep understanding of what was important to us as a business and then finding a company that fit in with our values. I’d also say that it’s worth running a test project together first. Even though these kinds of small projects are often fixed cost/fixed scope (and therefore not very agile), you’ll get a feel for work culture and their approach.

InfoQ: What about the agile values and principles- are they suitable for offshoring?

Lord: I think that when you look at the principles behind the original Agile Manifesto (which I think still hold true regardless of your methodology) then there’s only really a couple that are difficult to reconcile with offshoring. There’s a big emphasis in the Agile Manifesto on close interaction between business stakeholders and developers, on face-to-face conversation and on self-organisation. In practice I’ve found that whether a team is offshore, outsourced or in-house, a single person or small group of people are actually responsible for understanding business needs and then communicating these to a development team. Sometimes that’s a Product Owner or a Project Manager, but it’s a system that tends to work quite well with offshoring because communication can sometimes be difficult and clear lines of responsibility and accountability are usually required. There’s often a project manager at the other end as well so there is a danger that developers are too far removed from business stakeholders. I try to tackle that by making sure developers have a direct line into, at the very least, the product owner or project manager so they can seek clarification where required. We have a Slack channel that’s accessible to everyone at EdPlace and everyone at our offshore partner so anyone who has a question can get hold of the right person.

Face to face meetings are obviously impossible (though I do think regular trips to meet face-to-face are worthwhile), but technology is improving all the time and I’ve found that a combination of Slack and Zoom/Google Hangouts is good enough for real-time text communication, video calls and screen shares. There’s no question that sitting next to a developer and working through a problem together is beneficial and often results in quicker, better results, but it is possible to get close to this with an offshore team.

What I’ve found most challenging is helping an offshore team reach a level of self-organisation/self-sufficiency. It’s inevitably problematic because of the client/agency model - the team (and their management) fear that not following clear instructions may lead to conflict later in the relationship as expectations diverge. For me this is all about trust and building a strong relationship. It may also be about breaking down internal systems at the agency. For example, most will have a focus on time tracking for billing purposes and this leads to a time tracking mentality which doesn’t match well with agile. What worked well for us was working on expectation management - in both directions - so that it was clear how much leeway the developers had to manage their own time, their workload, and the way in which problems could be solved. Some of that was documented but other elements appeared organically over time. For example, in our Kanban system we gave the team written guidelines on how to prioritise issues (and trained our staff internally on how to write and prioritise their own issues) so that issues could be picked up on in the correct order without intervention by the EdPlace team.

InfoQ: How did you adopt agile to make it work for you?

Lord: Over time we adopted two methodologies - Scrum and Kanban - and adapted these to work with an offshore team. Kanban, which we use for production support tasks, is actually quite easy to handle with an offshore team. We started out with a basic Kanban board in JIRA with the usual ‘To do’, ‘In progress’ and ‘Done’ columns and then adapted this to include a ‘Ready’ column - meaning that an issue had been approved to work on by a member of the EdPlace team - and columns to show that a task was in QC or UAT before deployment. Then there were a whole host of swimlanes that were used to categorise issues - critical tasks, bugs, customer service requests, etc. The real key to success with the Kanban system was the development of clear guidelines, with example issues, on the order in which developers should pick up tickets. The ‘Ready’ state was really a stopgap until the team was self sufficient enough to look at the entire list and pick up tickets that they knew would be a priority for the team at EdPlace - that’s really important when you sometimes have a 5.5 hour time difference to deal with.

Scrum, which we use for feature development, was more complex to introduce and our implementation is probably better described as ‘Scrum-lite’ or even ‘Scrum-like’. Because Scrum is so ceremony-heavy, it doesn’t instinctively feel like a good match for a team that is thousands of miles away but with a few adaptations we found a good rhythm. We replaced daily standups with a check-in on Slack and made some changes to the way sprint planning and retrospectives worked. Planning was done in three phases: an internal meeting at EdPlace where we prioritised our top issues; a meeting of the team at our development partner to identify questions about these issues and provide rough estimates; and a final meeting between myself and the team to discuss their questions and revise estimates as necessary. This is a bit more long-winded and disjointed than the usual planning meeting but it seemed to result in accurate estimates and expectations. At the end of sprints we didn’t tend to run demos. That was partly a time-difference issue and partly a communications issue - most developers seemed more comfortable providing a brief written explanation of what they had completed.

The most challenging element of running Scrum has probably been handling estimates. Both the client/agency relationship and the work culture in India seem to result in estimates being taken as firm commitments by developers. Whereas I see revisions to estimates as an inevitable and welcome part of software development, our development team sometimes seems reticent about revising an estimate up, preferring to work late to fit it into its original estimate. Once again, I think it’s an issue of trust and of work culture. What I realised was that our developers were concerned about being seen doing lots of demonstrable work because they wanted to appear productive. Once I understood this, I was able to communicate my expectations more clearly and show that my focus was on output and quality, rather than the number of issues resolved or the amount of hours that someone worked. Continually reiterating these points over time helped the development team understand how important this level of transparency was to me - it wasn’t a quick process!

InfoQ: What have you learned from offshoring agile as a startup?

Lord: It can be done! People sometimes look embarrassed when they tell you that their prototype was built offshore or that part of their team is based in, say, Ukraine, but I think attitudes are changing. The local recruitment process for developers is exceptionally long and expensive and people are starting to realise that there’s a faster, cheaper way to do things. And as communication technologies improve, that process is getting easier and easier. Businesses of all types and sizes have been offshoring at least some of their workload for years but not necessarily working in particularly agile ways. What we learned as a business is that it is possible to achieve agility with an offshore team as long as you understand the limitations. Offshoring product ownership or user experience design is still high risk and error prone unless you happen to find someone with a high degree of domain, market and/or cultural knowledge. Similarly, hoping that your offshore partner will take responsibility for your technology strategy is a mistake. They can certainly guide you in the right direction but they will be blinkered by their own business needs. Someone in your business still needs a solid understanding of the technology that’s being used. If you don’t have that capability, then buy it in either in the form of a lead developer/CTO who sets the strategy and approach for the team, or a technology consultant who can do at least some of this.

InfoQ: When do you recommend to use offshoring? When do you recommend not to?

Lord: If you’re clear on what you want your product to do, want to get value for money, and have capacity to find a good partner (get recommendations if you can) and to manage that relationship, then I think you can achieve great things with an offshore team. However, if your product or project contains a high degree of technical uncertainty or the technology is the product then I think at best you can work towards a blended team with some of the team offshore and some based with you in your offices. I’d also say that if a culture of complete autonomy and independence is what you’re looking for, then offshoring won’t necessarily work. The client/agency relationship does interfere with that even after you’ve put a lot of work into the relationship.

 About the Interviewee

Will Lord is former CTO and currently board adviser at EdPlace, a London-based EdTech startup. Prior to joining EdPlace, Lord worked on a range of digital projects for charities including the Royal Horticultural Society, UNICEF, the International Rescue Committee and War Child. He spent several years living in Zambia and Zimbabwe, where he worked in design and communications roles for charity and business clients. He is currently a full-time dad and is taking a well-earned break from looking at computer screens all day.