Next read
Remote development challenges
Overcome project ownership challenges with managed teams
Bringing in ‘dedicated teams’ can create new project ownership challenges for product owners – Proshore's self-managed teams can be the solution.
Talk to Jeroen, our Accounts director, to see if our ready-to-code dev teams are a fit for you.
Whatever sort of software you’re developing, when you look to a solution like an ‘offshore development team‘ to scale and expedite your coding, you might be forgiven for asking: who’s in charge here?
After all, although they might be seamlessly integrated into your existing set-up, you’ve hired a ‘managed team’. But what does that mean exactly, and how does it impact project ownership?
What is a ‘managed team'?
A managed team is a group of external software developers, and other related roles, who are brought alongside to add expertise and scalability in the completion of a project, or a particular part of a project. The tech company leverages the skill sets and resources of the ‘remote development team’ to fulfill their goals.
These collaborations usually take one of three forms. Either, the managed team is the main developer and the client is a Product Owner, or they are brought in to enhance any existing in-house development capabilities.
In the second scenario, this could also involve working with other teams brought in by a client to achieve a particular goal. Both teams work independently on different areas of the same project using their own separate processes.
Thirdly, the teams might integrate, typically with an even number of developers from both sides completing the same backlog of work to be done.
How do the three main types of partnership work?
Sole development partner
In the first type of partnership, the managed is the sole developer and has exclusive responsibility for building the software application. This means a lot of decision-making and technical discussions are made by the managed team itself.
The client will have the brief and the managed team follows the roadmap they’re given using their own iterative process. In this scenario, the client’s Chief Technology Officer (CTO) will often assume the role of Product Owner (PO).
Team augmentation
In the second type of partnership, there is already a development team in place, and the managed team collaborates with them, drilling down and identifying chunks of work to be done.
In terms of ownership, this way of working can be more tricky because there is already an established development team when the managed team comes in at a later stage to add capacity.
Typically, the new team will work separately on different aspects of the project using potentially different approaches to development.
Integrated capacity
The third type of partnership is more integrated, with both sets of developers fully alongside each other as a merged team.
In this scenario, it’s important to establish who’s managing the project from the get-go.
No matter what the setup, it’s always a good idea to focus on the best way to move forward with clients using an Agile approach, working in short sprints of work to be done. In this way, onboarding is quicker, and it’s easier to integrate more effectively to deliver incremental blocks of completed work.
Best way to structure development teams
At Proshore, with larger products, we’re usually able to agree on a particular area to work on, for example when there’s a separate back end and front end. This creates clear and discrete workflows for each team. It also ensures there’s no overlap on the work to be done. Typically, in this scenario, we would have separate sprint goals and work more or less independently of each other.
Alternatively, we can work as a single team with both sets of developers addressing the same backlog of work to be done. We collaborate and do the refinement together, so from an outside perspective, we’re essentially one and the same team. Whoever we work with and whichever way we set up, above all else, the Agile way of working enables us to add value where it’s most needed.
We try to provide managed teams wherever possible because we have a scrum master, and sometimes we may even take the lead and manage the client’s teams as well.
From our side, it's always that Agile way of working that helps us to collaborate together, and that’s where we feel that we can create value for Product Owners.
Babish Shrestha, Proshore
Director of Technology
Ultimately, when we’re collaborating, the best setup is the one that is right for the client’s business and their needs. From experience, the most successful results usually come from collaborations where the teams are evenly matched in terms of skills and ways of working because they can integrate more seamlessly. More often than not, the right way of working comes down to a combination of the Product Owner’s preferences, the team setup, the maturity of the team, and each team’s roadmap. Managing two teams can be difficult, especially for those with less experience. Not only that, simply having more people to manage can be a challenge in itself.
Sometimes we find that the Product Owner is not experienced in Agile, so our focus is on communication and reporting, through collaborative refinement, review, and retrospective, which helps to define the team structure.
Final thoughts on project ownership
Wherever possible, we try to work collaboratively with a client, ideally, with an even number of developers from our team and theirs, all focussed on the same sprint goals. This takes careful management, so developers on both sides are fully aligned in terms of working practices and experience. Setting up as separate teams is easier in the beginning, but it can be trickier for the client to tie everything together further down the line.
There is no magic formula for getting project ownership right. The right approach to project ownership varies from client to client, project to project. No matter what the configuration, with our managed teams, we always try to take a consistent approach by using Agile methodology and by matching our experience and expertise to the customer’s needs.
When a partner uses an Agile approach, it’s much easier for us to onboard and integrate our teams. But if a Product Owner is not experienced in this way of working, we still try to embed Agile practices like regular communication. As an offshore development company, we need to be adaptable to suit the client’s approach to project ownership.
Here are 11 tips for managing remote teams if you choose to do it yourself. With Proshore, we take care of that for you.
6 minutes
Extra Capacity: 6 Ways To Work Well With Remote Teams
Looking to bring in offshore devs? Get our expert outlook on how to work well with your remote team – and how to get the best out of them.
5 minutes
Overcome project ownership challenges with managed teams
Bringing in ‘dedicated teams’ can create new project ownership challenges for product owners – Proshore's self-managed teams can be the solution.
3 minutes
From micro to self-managed Remote Software Developers
Learn how one of our clients, CMNTY, was able to scale without intensive micromanaging through our self-managed remote software development model.
Looking to hire offshore developers?
We can help you get started in 15 minutes.