All Onboard: Overcoming the challenges of project ownership with managed teams
Whatever sort of software you’re developing, when you look to a solution like a ‘development team as a service’ 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’ in software development?
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 ‘development team as a service’ to fulfill their goals.
These collaborations usually take one of three forms. Either, the ‘team as a service’ is the main developer and the client is a Product Owner, or the ‘team as a service’ is 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?
In the first type of partnership, the ‘team as a service’ is the sole development partner 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).
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.
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.
What’s the best way to structure development teams?
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.
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.
Where 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 a development team as a service, we need to be adaptable to suit the client’s approach to project ownership.
How a mentorship program can kickstart software development careers
Staff augmentation vs project outsourcing – what’s right for your company’s IT needs?
10 benefits of IT staff augmentation
