The initial idea was to start with a 3-month pilot project that would touch all parts of the current SDLC process. The goal of the pilot was to build mutual trust and set the framework for future cooperation. We started with 2-weeks of onsite workshops with 2 developers, working side-by-side with the team in Finland. We then switched to a fully offshore mode, while keeping regular visits both ways. The initial phase was a big challenge, not only because of the transfer of knowledge, but also because of the fact that all the IT work had only been done internally so far. Thus, we had to set up a whole framework for remote work including: the right communication channels (written: slack, spoken: daily stand-ups over video using Skype for Business), practices regarding work planning (e.g. every other sprint planning done onsite) and tracking (JIRA) or even basics like access to environments and tools (e.g. VPNs configuration).
Eventually, the pilot ended half-way through with full success: the work was delivered, and the foundation for cooperation built. We were ready for the next step.
The next step was testing the foundation we had laid down with a full team not just two people. So, we first built a full team of four developers and one QA and started on our way. Down the road, we also introduced changes to some parts of the development process like: TDD and Continuous Integration or Continuous Deployment. We also had to switch all internal communication from Finnish to English (it was not that easy, but in the long run easier than learning Finnish…). Luckily for us, customer management was ver supportive at all stages.
Finally, after roughly half a year we had the green light to start real scaling by adding more teams.
Since our custommer’s business was still actively growing, during the next two years we’ve established five independent scrum teams in Poland, with a total of 30 people (Architects, TLs, Developers and QA Engineers). In order to make the process less consuming for the client we decided to build new teams in 2 steps: first, adding developers to current teams and second, start a new team with people that already had the knowledge about the business context and internal procedures. Currently, both sides feel that Software Mind teams are a natural part of the in-house team. Our people are involved in architectural meetings and have a significant impact on how the product will look like in the end. There is not a client-vendor type of cooperation but rather a partnership of equals. Overall, we are all working on the same goal: using technology to maximize the business value of the product.
Currently, five offshore independent teams from Software Mind are working together with similar teams onsite, but as the business is still growing, we haven’t stopped expanding our cooperation. We’ve got ambitious plans to keep current team growth, while reaching 50 people in the near future, while still keeping the quality we had in the first place.
One of the things I like the most about this case is the approach we used to gain our client internal IT team buy-in, which is extremely important when introducing outsourcing for the very first time. First, our client introduces outsourcing openly addressing some of their team worries like losing software quality, cultural differences, or even the fear of being left out of a job in the long run. We then began the social introductions by organizing several onsite visits and working side-by-side for some time (including visiting Finnish sauna’s as a mandatory point ☺). Additionally, one of our client’s developers joined our team for a few sprints (“let developers talk to developers” approach). He eventually became our great internal promoter in the organization, helping us reach out to the right people to get some issues sorted out. Finally, we went even further in integrating both sides, for example we recently organize a shared hackathon running parallel in two locations (some developers travelled from Poland to Finland and vice versa).
There are of course things we could have done better (like spending more time on reducing technical debt or introducing QA automation a bit earlier – we are facing those challenges right now) but eventually we lived up to the challenge of scaling IT capabilities to keep the pace of rapid business growth.