Building agile teams in India Pt 2: Assessing your readiness

Part 2: Assessing our preparedness

Checklist: Were we ready to offshore
The checklist I propose below didn’t exist for us. I wrote this checklist with the benefit of 20/20 hindsight. I wish I did have something like this when we started, but hopefully what we learnt is of benefit to others.

Are you ready for your offshoring to take up to 5 years to ROI
Have you sold the ‘purpose’ to the ‘home’ team (leadership and teams)
Are you prepared to place trust in the offshore team to make decisions
Will the offshore teams have meaningful work (i.e. NOT bug fixing)
Will your budget include a ‘building trust’ component
Do you have a ‘local’ who is prepared to relocate
Are you prepared for it to cost 50-100% more than your initial estimates/assumptions
Are you prepared for it to fail? Do you know what failure looks like
Are you prepared to take a risk on another location outside the obvious
Have you considered the various models for offshoring (e.g. Outsource captive, BOT, Offshore etc)

5 years to ROI
It takes a significant investment in time and people to successfully set up a development centre offshore. Recruitment can be difficult, transferring knowledge is hard and you will make many mistakes before you get it right.
If the organisation has a long term strategy in mind than this is fine. However, if it is imperative to cut costs and have software delivered at the same pace, than offshoring may not be right for your organisation.

Selling the purpose to the ‘home’ team
When planning to set up an offshore team, one of the first things you’ll need to do is plan for change management. In this instance making sure the ‘home’ team are not threatened by the establishment of an office in a cheaper area.
Inevitably, setting up in India or elsewhere in asia will cause staff to fear their jobs. If the purpose of setting up a 2nd development centre is not intended to ‘cut’ the home office the sooner this is out in the open the better.

Placing trust in the offshore team/Meaningful work
This is a key component to success. If the offshore team is to be an equal partner, than working out how to ‘trust’ them to handle meaningful work is key. This means, work that contributes to company strategy beyond just ‘bug-fixing’ or maintenance. Trust is an essential component to ensuring the teams are able to work without constant handholding, greatly increasing efficiency.
In Aconex, the work was ownership of key products in the companies portfolio. This has led to greater satisfaction in our Indian office, however, there are a lot of trust building exercises that got them there.
One method is to make sure there are regular visits between the two locations, not just for the senior staff members on the teams. Including budget line items such as “Building Trust” and scaling that budget based on the following formula might work:
If the team is all ‘local’ than a pizza per week per person might suffice. If the team has a number of people in remote locations, than the budget could include X number of trips to each others office per quarter. This makes ‘Trust’ an explicit concept for debate when conversations about budgets take place “Oh, you want to slash the ‘trust’ out of the budget?”

Getting a ‘local’ in the new office
Having a home office rep in your new office, at least for the first year or 2 is a great help. All the successful companies we spoke to had this in common. It enables the new staff to have a point person to help them find the right person, understand cultural differences and help make decisions.
Often, the ‘local’ expert can help with simple things like “In Australia, when someone says …, does that mean they’re angry with me?”. 

Cost overruns
Most valuations on costs to offshore do not take into account the fact that a boutique agile office will cost a lot more than a basic BPO or Services set up, but expect it to cost 50% more than you think and you’ll get close.

Some key takeaways

Be prepared to offshore meaningful work – give teams ownership of products
Don’t rush the hiring – recruit for cultural fit as well as technical skills
Headhunt your key people
Consider using a known agile consultancy to do a build, own, transfer model (BOT)
Put local (home office) people in for extended durations from the beginning

Comments

Post a Comment

Popular posts from this blog

Using an agile storyboard as a scale of certainty

Image
As per my previous post, In my current team we have started using a 'Just in Time' (see how I feel weird about saying Kanban, not sure why yet) approach to doing various activities around development. Mostly this is around planning, but in that sense, we are also doing as much Just inTime as possible in giving an estimate. Scene setting We are a team that does 2 week sprints, but we also don't do a major release at the end of each sprint. We tend to wait for 5 sprints to pass before we do releases, there are a number of organisational reasons for that, but suffice to say, thats the way we do it around these parts. Our story wall (in ugly table form) The table below is a basic representation of our Story wall. As you can see, for the story wall, we deliberately do not just focus on the current 2 week sprint. We also have columns heading beyond the current sprint to encapsulate the entire release timeline (in this case the team have already completed two sprints so their are
Read more

A survey on release processes with organisations that 'sef-identify' as folowing agile practises.

Image
Earlier this year I ran a survey around ‘release processes’ specifically with companies that follow agile practices. I promised that I would publish the results and apologies for the delay, I have collated the responses below. Thanks to everyone that participated, really appreciate your time and energy. At iflix we're always looking to improve our release processes so it was really great to get so many good responses. We learnt we're not that far apart from our peers out there. We've got a lot to learn of course, some of that comes from hearing from others and some from the mistakes we make. The trick is to make your mistakes small ones and learn fast with minimal disruption to your customers. This survey was run at least 5 months ago, so it’s a snapshot in time.  Most places I have worked change their processes (inspect and adapt!). I've reproduced the responses in their entirety, so it is a bit of a long read. I’ve anonymised the responses somewhat, retaining
Read more

Mission Orders, 6 military principles that can work for agile teams

Yesterday, I was watching a documentary on the "Battle of the bulge" A famous battle in World war 2. The docu makers were investigating German tactics during the battle. Specifically, tactics which had worked so well early in the war, over extended periods of time, towards the end of the war, fell apart after 3-5 days. Early in the war, German officers had Mission Command, that is, Hitler and high command had high trust in their teams. As the war went on, and things started to go wrong, mission command was gradually eroded as trust fell (especially when his officers tried to kill him). Mission command basically means, set the goal, let the teams be responsible for how they are carried out. Training is centred around this, discipline and training carry you through the unexpected, as long as you know the end goal. Effectively, the German high command no longer trusted the lower ranks, and only gave them enough information, goals etc for the immediate goals and set them
Read more