4 Pillars of Growing Offshore Development Teams

So I have been working with building offshored software development teams in Ascentic during the last 4 years now, and picked up a thing or two about what makes it work and not. Looking at the 4 points you might feel these are applicable to any software development, and not only offshored. Yes, that’s correct. These pillars in my experience are great for any growing software development team, they just become extra important when your team is geographically distributed.

1. A Strong Product Ownership

Now what is this Product Ownership or Product Management that everyone is talking about? Put simply, the Product Ownership (an individual when the company and product portfolio is small — a group of people when the company is growing) is a 2-way funnel between The Business and The Development Team. A little like this:

As well as like this:

So why is this important in a distributed (and growing) development team? Well basically, without the PO-funnel we tend to have The Business blasting product requirements into The Development Team without priority, plan and consideration of how different requirements impact each other — and in return a Development Team blasting out product releases that will for sure clash. If there is one core competency to focus on in your inhouse team — I’d put my money in Product Ownership.

2. I’m sorry to say this, but yes, Documentation

I know, I know. Everybody hates documentation but at some point, your growing team will start hurting a lot with the lack of it. I’ll keep the propaganda short and just give some tips that I find useful.

• Assign a Documentation Structure Guardian — a structure freak who creates the framework for how technical and functional requirements should be managed and who makes it his/her lifelong task to make sure whatever goes in there — and stays in there — is accurate, up-to-date and trustable.
• Create an New-to-the-Team-Onboarding-Checklist. One of the big downfalls with poor product documentation is that as the product and team grows, you will start spending an increasing amount of time explaining the ins-and-outs of the product for all newbies (and yes, this also requires that the onboarding person actually KNOWS the ins-and-outs of it but let’s not go there, I promised to keep it short). This consumes time and the risk is high that a lot of important stuff gets missed in the process. With a proper product documentation — you can simply create a checklist pointing the newbie to the material he/she needs to go through.
• Don’t stick just to text! Use short demo recordings of the product, screenshots and other content types to make sure the content is understandable and clear.
• Remember the techie-docs — coding standards, practices that all developers in the crew are expected to follow, as well as technical designs and blueprints. A large system that has been developed for a long time will most definitely have a lot of personal touches from the different people building it, and to minimize the amount of brainwork going into guessing “what John was thinking when writing this puzzle of a code snippet”, stick to standardized and frameworked stuff as much as possible and let the team know the rules of your technical castle.

3. Process — Process — Process

One of our customers once said:

“The good thing about working with an external partner is that it forces us to become more professional in our processes.”

Yes, when your team is distributed and as the company and product is growing, defining and following a plan for requirements — development — test — release is a good idea. Now this obviously covers a great deal, a few things that really matters are:

• Requirement management — how do we make sure all relevant requirements are channeled into the product ownership, and how will they get the required input (technical feasibility, dependencies, priorities, budget) to turn that into a product roadmap? (Tips — Product Board meetings where both business and tech is represented and plans for the upcoming months are discussed!)
• Testing and quality assurance! Who should test, what environments and data should they use, and what should be the criteria for putting a task to “Done”? Who does the code reviews? What test strategy should we have to ensure we cover all possible impacted areas, as well as the user experience aspect? As your platform grows, I highly recommend getting dedicated testers into the team. Your testing coverage and output will improve immensely when it’s not done only by the people who has built it and knows how it should be working (that is, when the users do as they are supposed) — but actually act as your future unpredictable and erratic users are likely to do.
• Set a release frequency and decide on the practices that should go with each release — for example who should be informed about the new stuff coming out and how (a demo meeting for the sales crew? release notes? a newsletter?) and how often should we release (once a month? every other month?). Releasing ad-hoc — whenever we have something useful to release we’ll push it! — is of course one strategy but again, as the team and complexity grows it’s maybe not the ideal way to go. Having a strict schedule tends to help the entire organization to plan accordingly.

4. Plan It and Talk About It. A Lot.

Yes we all want to stay agile and not get stuck to a 5-year plan, but setting a short-term and long-term plan for the development is really important when your team is distributed. What you lose when your development team is not sitting in your office is all the chitter-chatter going around the office giving the big-picture context on what we as a company are building — why we are building it — for who and what they care about.

What do we want to achieve during the upcoming 3 months, and what is the longterm vision for the product we are building on? Having a clear picture on the focus areas and priorities for the product ahead empowers the development team to — crazily enough — consider it. It allows them to come with better suggestions and input on how to build the feature for the next release — as they know how that will benefit or block future areas of the product. If your business context is expected to change so rapidly that even a plan for the upcoming 3 months is not motivated, having a crystal clear plan for at least the upcoming 1 or 2 months become even more important. That way your team can focus on getting the important stuff out during that period of time and then be ready to take on the next business opportunity.

And yes, the plan can change. It should change over time. The good thing is, if we have a plan defined, it’s also a lot easier to communicate about how it has changed, when we come to that.