Let's call it Application X* (the software is real, but I changed the name).
When a few years ago our developers first looked at the existing code of Application X, they were not exactly happy. It wasn't the cleanest they've seen. It was far from the standards they got used to. PHP was polluted with HTML and MySQL queries. The names of variables were not in English, but in the client's native language. The project tracking solution used by the client's dev team so far was clunky and the development methodology was in its infancy.
These were some of the challenges we faced after we decided to take over the development of Application X. So, what happened?
Refactoring the old, improving the new
First of all, the existing modules were divided into two categories: "rewritable" and "non rewritable". The rewritable were the ones which could be refactored or rewritten by us with reasonable effort and minimum conflict with other modules. This is how we tackled some of the imperfections in the legacy code. The ones we deemed "non rewritable", for various reasons, were left as they were. All the new modules were written in the new, cleaner manner.
The decision which modules were "rewritable" and which "non rewritable" was also the first exercise in communication and partnership building. Because engagement of teams on both sides is one of the key factors of success, this initial effort laid down the foundations for a symmetrical relationship in the future.
Improvements in quality
As the project progressed, several decisions to improve the quality of development were made. With test automation came less dependency on manual work. Continuous integration helped with early detection of errors and, thanks to daily builds, increased the stability of the application. CI also assured faster, easier and more reliable deployments.
We also introduced peer code reviews, which let us eliminate a number of imperfections in the early stages of development.
The dawn of JIRA
Back in the day, our customer was using a project tracking solution, but it was not really living up to the standards of good team collaboration practices. At that time, we were already big fans of JIRA. For a while we used it together with our customer's solution, but it wasn't efficient, as you may imagine. As the cooperation tightened we started a conversation about the benefits of using a single tool in both companies. We discussed it for a while, but JIRA was on the rise and became an obvious choice very quickly.
SCRUM
In hindsight it was easier to refactor the code, or adopt JIRA, than change the habits of our teams on both ends. To be fair, we were not pushing for SCRUM very hard, although we felt that it was inevitable that this was going to happen at some point. Especially when the team grew and informal methodology could not cope.
We were leaning towards SCRUM, because we had been using it for a while already in different projects and it was our rough guess that it would would work in this case too. Switching to SCRUM is not effortless: it involves more maturity and better organization, which is something people sometimes accept reluctantly. So we thought - "no pressure". We actually waited until some new people joined the customer's team and we found out that we could do it together.
The thing about software houses
It's not uncommon that a nearshoring company, usually a software house, takes over an existing project. It happens when the capacity on the client's side is close to maximum. Or there is an urgent need for new features. In such situations, more often than not, the project methodologies and coding practices are not exactly the same on both sides. The teams have different visions, experiences and habits, which may cause friction.
Of course, such a clash of cultures may result in tension, but it may as well lead to really good things.
Many software houses are melting pots of good and bad practices, communications standards, programming guidelines and QA approaches. It's because they work with multiple clients, and they learn something from each cooperation. In fact, they have to do it. As they are rarely verticalised, their core business is in good programming, not in understanding a very specific industry. Apart from delivering software, they are often instrumental in bringing cultural change to their customers.
