Every day, more companies rely on contractors when they want organizational flexibility but require high skilled resources when crafting digital products. Being able to grow their development force in very short notice without the hassle of training and hiring has an incredible appeal to companies big and small. However, for companies already implementing Agile (or wanting to dive into it), adding contractors to their product teams adds an interesting challenge.

Agile is more than a methodology, it’s how we describe organizations committed to the premises of the Agile manifest. When we talk about Agile, we mean:

• Customer satisfaction as the main drive and metric
• Frequent delivery of working software updates
• When facing uncertainty, don’t freeze: try something, get feedback, and adjust accordingly.
• Self-managed, empowered teams
• High transparency and communication
• Continuous self-evaluation of the performance, therefore the team is always improving.

If you are a company using or considering Agile, and you’re thinking about hiring contractors in the near future, keep reading.

Choosing the right partner

Your contractor should already be fluent in Agile. Tech leads and developers should already have an agile mindset and experience working in agile environments. Otherwise, you’ll have to invest time in introducing them to the methodology, which is going to come from your company’s budget. Also, there’s no warranty that there is a commitment to the Agile way if the contractor doesn’t already have it in its culture’s DNA. The ideal partner will want to know everything they can about your business and will show a commitment to your long-term success, aligning themselves with your goals.

Contracting Agile

If your company is new to Agile and/or wants to benefit from the expertise of an Agile partner to level-up its game, this could be a golden opportunity. On top of expert developers, an Agile partner can include a Product Owner and a Scrum Master in the team, as a way to train your personnel in Agile Development. This way, from stakeholders to developers, including managers, can benefit from agile coaching during the product development process until the in-house team feels comfortable enough to step up and fill the PO and SM roles by themselves.

But, is it OK to have an external Product Owner?

Don’t be fooled by the name. Having the Product Owner in the supplier side has its benefits:

• Already knows product ownership’s best practices and probably has a lot of experience from previous projects.
• Can contribute to product design and roadmap decision-making, bringing feedback, fresh ideas and possibilities that result from agile iteration and updated value metrics.
• High technical background and familiarity with the internal development process., thus giving them a 360 degree view of the project.
• By supporting both corporate needs and those of the development team, PO can be a powerful liaison between the two, specially because the trust of the latter is already a given.

Of course, it also has downsides. Let’s see some of them, as well as ways of mitigating them:

• Not familiar with the market and the business: If your partner’s past projects and expertise include similar projects and/or can denote high adaptability in a wide range of products and markets, they won’t have a problem familiarizing with your company’s market in very little time.
• Not acquainted with the company’s culture : A good PO can pick up culture cues very quickly, especially with the high frequency of personal exchanges associated with the agile process.
• The leadership role could be hard for the company’s stakeholders to get used to : The key to mitigate this is understanding that the PO is a servant leader. A PO is someone who aims to achieve authority, not power, focusing that authority in answering the needs of the organization and the team. If the stakeholders can measure the impact of this trust quickly, they’ll start trusting this agent in their close circle and benefit from their help.

By letting an agile-savvy provider help the team, a company new to agile could benefit faster from it than starting from zero. Even if the company has already started to use agile, it could learn from a more-experienced partner’s ways as a way to train its key employees. One of the most important requirements for a high-performance agile team is having a well-kept backlog composed of adequate-sized and well-written user stories. Having a PO that is closely related to the tech aspect of the development and who has a good and close relationship with the developers has proven over time to be one of the most important factors of agile software development.

The PO focus will change over time, according to your product current stage:

• During the discovery phase: the PO will be close to the business, working on vision, needs, backlog & product strategies.
• During the project kick-off phase: the PO will be close to the development team, vision review, roadmaps, technical evaluations, refining project strategy.
• After the production phase: the PO will be where he is needed, being a leader servant to end users, other stakeholders or the development team.

What happens if I already have a PO? Can I use their PO as a proxy?

Having a proxy PO usually weakens their role in the team, because their role is merely a filter for requirements, when he should really be both accountable, and in a position of making fast, meaningful decisions. He could help the existing PO in the backlog management and user story creation, but his talents would be underutilized and overhead will be generated in the agile process. Having a high-skilled PO peer-training the company’s PO could result in a better investment for the future.

If you trust your contractor enough, their insight can be highly beneficial for the future of your product. Consider including an external PO, even if you already have one, it could take considerable weight from your PO’s shoulders and gain him an invaluable ally in the journey ahead. And why not?, coach him to be an even better PO.

What is needed to make it work?

Transparency : Every Agile team should have access to performance metrics. Both client and provider should agree on the right objectives and key results. If the vendor is your partner on Agile and their PO is a key part of your product, you should commit to an outcome-based metric. User feedback, value indicators and feature use metrics should be available to the whole team in order to self-evaluate their performance and adjust iteration after iteration to boost their performance based on product value (metrics). Disconnecting the team from the value delivered and confining their vision of performance to just “story points delivered over time” would be a huge waste of Agile value.

Empowerment: The company should empower their partners to make decisions and move forward between meetings, rather than waiting for permission from stakeholders. If they make a mistake, it can be fixed—thanks to the fast iterations of agile methodology. Giving an external PO the trust and power they need to go forward, will result in faster iterations and better performance. The percentage of errors will be minimal compared with the huge progress the team will make, when not constrained to long waits for answers that can be easily provided by their own PO.

The challenge of unified culture

When implementing Agile, one of the main practices is to build a shared culture, where everyone understands the importance of agile practices and the responsibility of each player. With the new reality of remote work, it’s even harder to think about this, specially if the development team is composed of a mix of company and partner’s developers, interacting with several company departments. Agile Ceremonies could be the foundation of a shared culture: daily meetings and retrospectives could create a common ground and a team spirit, even if developers don’t share an office or belong to the same company. Even if they dedicate their day-to-day efforts to the same goal, it’s also important that they celebrate every single achievement together. It’s a common mistake to address them separately when it comes to congratulating and reporting problems. If you want them to feel like they are in the same team, they should feel like it. Don’t rule out periodic in-person activities that can act as team-building exercises that bring together both company and contractor employees.

Try to keep a low rotation in the team: on your side, you should put some effort in keeping developers and managers long enough to profit from their experience in both technical and agile knowledge. Ask your partner for a reasonable permanence of their developers, PO and Scrum Masters as well.

Sources:

Agile Contract Models – Working with Cross-Corporate Teams

When Agile Meets Outsourcing

IT Outsourcing: Should the Product Owner come from the Client or the Provider?