Service companies often find it hard to instill product thinking in teams. People working on software applications believe that they are only on a temporary project - that could range from a few months to a year. When it’s done, they can move on to other projects. The application is seldom treated as a 'product', that needs to live in production for many years after the project is completed.
We’ve worked with a large online travel company for over seven years now. We’ve seen both long and short term projects. In fact, at one time, our team of 100 people were working with a client’s in-house development team of 50 people! This experience taught us many lessons and I’d like to share my experience in this post.
Our application architecture was such that it had 3 web components for different channels and around 20 services (6 of them being major ones). We had 8 features teams across two locations making changes to these web components and services. Each new feature development was termed as a “project”. Usually, a project would span across multiple services and couple of web components. Every team was working on different web components and services in order to meet the requirements. Each team had its own style of design and coding and hence there was no consistency in the code. It was a nightmare to maintain a codebase with 150 people checking in code simultaneously.
Reality struck when our client decided to reduce the Thoughtworks team size and increase their own capacity. Ordinarily, this would be a routine knowledge transfer phase. But given the size of our codebase, it proved to be quite challenging. An exhaustive knowledge transfer required us to change our own mindsets - we had to stop thinking of teams being part of projects and start thinking of them as being owners of products.
Every service and web component was a product now. We had 5 teams owning these products. Code check-ins in each product repository was restricted only to the owner teams. This brought in lot of confusion at the beginning, because almost every project (feature) needed changes in multiple repositories by multiple teams. This increased the feature rollout time but improved the code quality and consistency.
We identified teams to own services and web components. We transferred knowledge for 6 major services and 2 web components among 4 different teams at the client end. We retained a web component with the Thoughtworks team. This way, we didn’t have to transfer knowledge of everything to everyone - but only transfer targeted knowledge to relevant teams taking ownership. By now, each product had its independent repository and owning team.
Changing our mindset from being project aligned to being product aligned transformed the way we did the knowledge transfer. But apart from this, there were many long term benefits, to name a few:-
We learnt quite a few things as we moved on. Here are some of our learnings:-
Changing our way of thinking had a huge impact on us. We were now thinking and talking about products that can be maintained easily, which have less or no production defects, technical enhancements in the products, etc.
One very important change we observed was reduction of tech debts. Earlier, a team working on one project would get done with that feature without removing or sometimes building on top of the existing tech debt. But now, teams did not move ahead with feature development without removing the tech debts, and building on new tech debt was out of question. Our teams’ behavior changed from “everyone is responsible but no one is accountable” to “take ownership and be accountable”.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.