For over seven years I've been working as a Product Owner in software development companies that use offshore development teams. For the last three years we've adopted Agile methodologies, in particular Scrum.
As you can imagine, using a highly collaborative approach such as Scrum has its challenges when your development teams don't share a country never mind an office, have different time zones, languages, customs and so on. When I first started looking into Scrum I found the internet strangely sparse of advice and experiences of using Scrum in the offshore scenario so I decided to jot down a few learning points.
As you can imagine, using a highly collaborative approach such as Scrum has its challenges when your development teams don't share a country never mind an office, have different time zones, languages, customs and so on. When I first started looking into Scrum I found the internet strangely sparse of advice and experiences of using Scrum in the offshore scenario so I decided to jot down a few learning points.
1. Use the Right Collaboration Tools
Collaboration is key. Geographically dispersed teams working in different timezones will need to get together virtually on a regular basis, and also have the ability to start ad hoc meetings or conversations.
We have found that Yodiz (www.yodiz.com) to be a good tool for managing the various Scrum artefacts including the Backlog, User Stories, Sprints, Epics and so on.
Yodiz does have an API but if like ourselves you haven't found the time to write the code to integrate this with your code repository (we use Gitlab) then you will need to do some manual trickery to move the Sprint tasks across to Gitlab.
Skype is ideal for screen share, voice calls and video calls. We tend to do the latter with all of the team together in the same room in Bangladesh as otherwise it becomes too chaotic to manage.
We're starting to use What's App for text chat, simply due to its enhanced security features, especially when working on client specific projects. The problem with chat is that you end up with multiple chat rooms and it can be difficult to track discussions. Keep a history of all chats and don't let ad hoc chats replace Sprint meetings where you can all catch up on progress and the current stat of play.
We use Google Docs for document storage and collaboration, which is key as we still write detailed design documents with workflows, If This, Then That descriptions, data models, wireframes etc and then refer out to this in the Sprint Tasks. The design doc is managed by the CSPO who is responsible to ensure it is up to date. So once the Sprint is complete, the design document is updated to reflect what was actually delivered, which hopefully isn't a lot different to what it said before the Sprint began (otherwise you may want to review your requirement capture processes!).
2. Find the Right Training Partners
We have an office in Bangladesh with some very talented coders. When researching Scrum trainers we found plenty of courses but when we looked at the detail we realised they weren't accredited trainers or that the training they delivered wouldn't qualify our developers to be certified.
The courses were also expensive as it often involved the training company sending a trainer into Bangladesh for a week.
We found cheaper and better quality training over the border in India. Find the company and course you're happy with then negotiate for them to send a trainer to you, or as we did initially, send a group of your developers to them. It works out better value for money in the long run due to the higher quality training and accreditation available, and with cheap Air India flights it's not necessarily a more expensive option.
Another key point on training is find a training company who delivers Scrum training consistent with your approach. To be fair our approach is mostly based on the approach of the Scrum Alliance, purely as that's who our first CSM and CSPO were trained by. The problem comes when you use a different trainer who's approach is different in several key ways. It is probably still very good training, but the confusion it causes when your newly trained Scrum Masters don't agree with your approach because it's different to what they've been taught is an interesting problem to have.
3. An Offshore Scrum Master is God
CSPOs everywhere will be up in arms at this next piece of advice, but so be it. In an offshore scenario where the CPSO is isolated from the core of the team which is offshore, the Scrum Master is key. If you can afford a Scrum Coach (not necessarily dedicated) in the offshore office, then that's even better. You will rely on the CSM to be the eyes and ears on the ground. He needs to have an expert understanding of the Agile processes, tools and artefacts and importantly how your organisation uses them.
You can't rely on the CSPO to be the driving force of the project if they're geographically isolated, so the role of the CSM becomes even more important. This makes it more important to also ensure as many in the team are Scrum Master trained, so they can take turns in managing sprints, releases or projects.
The Scrum Master is also key in running the local end of the Sprint Planning Meeting where the Scrum team will decide and provide estimates for the tasks. Some aspects of estimating need team members to work closely, perhaps using cards, paper or (I've seen it done) a magic colour coded dice. The Product Owner will need to trust his Scrum Master at this point and let him run that part of the meeting, and the Scrum Master must then be able to summarise what has been decided and why, and bring the Product Owner back into the decision making process in a seamless way.
4. Stay Focussed
Unlike teams that are more or less constantly in the same physical office, offshore development teams are seldom complete all of the time. In our organisation the CSPOs are based in the UK and, as mentioned, the CSMs and Scrum developers are mostly offshore, in Bangladesh. This means that as a CSPO it's easy to get distracted with other projects and tasks. The CSPO needs to make time for Scrum meetings so that the precious time the team is complete and together (though virtually) they can be productive.
5. Treat Virtual Meetings Like Meetings You're In
It's easy when using Skype, Google or other virtual meeting tools for a meeting to drift in and out, be distracted by email popping in on another screen or simply wandering off to the loo. Don't be disrespectful to your distant colleagues, or yourself and if you're in a virtual meeting, be in that virtual meeting 100%. In a traditional face-to-face gathering most would consider it rude to flip open your laptop and start doing your email, answering another phone or just wandering off without explanation or apology. So don't do this in virtual meetings. You'll inevitably miss something or worse delay the meeting or affect its productivity.
Turn off your phone, shut down your email and other apps. Immerse yourself in the virtual meeting and you'll make the most of your valuable time together as a team.
6. Be Clear on How You're Going to Use Scrum
Scrum is agile, it's a flexible approach to software and product development. As such there are a multitude of combinations of Scrum artefacts, different tools for using these, different team sizes, sprint lengths, different approaches to writing user stories and so on. Ensuring that the entire Scrum team is on the same page, using the same artefacts in more or less the same way is especially key in the offshore scenario. The role of the Scrum coach (which could be the CSPO or CSM) is important to ensure that everyone is clear how your organisation uses Scrum and that any concerns or questions they have can be explained clearly and, most importantly, consistently.
As your use of Scrum evolves, as you start to master the process and its tools as an organisation, ensure that you all move forward together. That eureka moment when the CSPO discovers the simple, effective beauty of the If This, Then That tool will cause havoc if the rest of the team don't understand its use and you suddenly surprise them at the next Sprint Planning meeting with a backlog full of user stories written in this unfamiliar format.
7. Keep Sprints Small, but Not Too Small
As you're working over multiple sites and spending less time together than a co-located team, don't make sprints too long or too complex (i.e. keep the user stories used in a sprint short, simple and of a limited quantity).
Also, don't be tempted to mess with Sprints once the Sprint Planning meeting has agreed their scope and content. It's easy to add new user stories once the project has started, but this will inevitably extend the sprints and before you know it (believe me I've been there) you're on a 3 month sprint and agile has become cumbersome. If there is a major new requirement (e.g. an epic) or you've spotted a major bug that needs fixing, don't just lump it into the current sprint. Be true to the process and stick it in the Backlog with a high priority so it's picked up in the next sprint. Finish what you've committed to before extending the scope.
8. Continually Improve
I personally don't believe in the "right first time" approach when it comes to product or software development. It works fine in manufacturing when the build process is nailed but in product development you need to learn as you go along. Things you try won't work in your scenario, try something else or tweak it. Don't be afraid to take the artefacts and processes you were taught on your training course and modify them to work best for you. Don't get parochial when an approach you thought was cataclysmic doesn't work for the rest of the team and they want to ditch it for another approach. Listen to the problems and challenges the offshore team are facing and try to work with them in refining your approach to Scrum to get the best out of the way you work and to overcome any geographical, timezone or other physical obstacles.
What I find I like the most about the agile approach to product development is that it's generally a lot of fun. When I think back to the traditional project management I've done, the stresses were mainly caused by the pedantic tracking, the mundane tasks and the lack of flexibility.
Comments