Working with vendors in a Scrum project

A vendor changes the geometry of a Scrum project. The vendor has its own priorities, its own managers, its own pressures, and often a contract that says what it will do and what it will be paid. The team inside the company inspects and adapts every Sprint. The vendor may be paid to deliver against a specification written months ago. Scrum's tools do not disappear in this setting, but they need to be placed with care.

What the sources say

The SBOK® Guide lists vendors among the non-core roles: external individuals or organisations that provide products and services that are not within the core competencies of the project organisation. Non-core roles are not mandatory, may not be continuously involved, and still matter in some Scrum projects.

The Scrum Guide does not mention vendors. It gives principles that apply. The Scrum Team consists of one Scrum Master, one Product Owner and Developers, with no sub-teams or hierarchies. The Developers are "the people in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint". When several teams work on one product, they share a Product Goal, Product Backlog and Product Owner, and must mutually define and comply with the same Definition of Done. If the organisation has a Definition of Done as a standard, it is a minimum.

Read together, they imply a simple rule. A vendor who builds part of the product is, in effect, Developers working on the product, or a dependency outside it. In both cases the product's accountabilities should not be handed over with the work.

Three models

1. The vendor as part of the team. Vendor staff are Developers in the Scrum Team, working with the Product Owner and the others in every event, drawing work from the same Sprint Backlog and meeting the same Definition of Done. The contract is for people or capacity, often time and materials. This is the closest to Scrum: the vendor staff are inside the loop, and the team is cross-functional in practice. The risk is that they are managed by their own company in ways that conflict with the team's self-management, such as reassignment.

2. The vendor as a separate team on the same product. The vendor has its own Scrum Team working from the shared Product Backlog and the same Product Owner, in the same Sprint rhythm. Its work is integrated into one Increment, with a shared Definition of Done. The contract is for a team and outcomes. This is the multi-team arrangement the Guide describes. The risk is integration and communication across organisations. See one Product Backlog for several teams.

3. The vendor as an external dependency. The vendor delivers a component or service against an agreed interface, on its own plan. The team treats it like any outside dependency: it is on the roadmap, its risks are tracked and its deliveries are tested against the interface. The contract is for a deliverable. See dependencies in Scrum. This is the weakest fit for empiricism, because the vendor's inspection and adaptation happen elsewhere.

The first two give the most of what Scrum offers. The third is common and works best when the interface is stable and small.

What to keep in the product team's hands

Whoever builds the pieces, certain accountabilities should stay with the product's own people.

• The Product Goal and the order of the backlog. The Product Owner decides what is built and in what order, including the vendor's share.
• The Definition of Done. It applies to vendor work. If a vendor's idea of done is "delivered", the Increment will suffer.
• Acceptance. The Product Owner or the team accepts work against the criteria and not on the vendor's word.
• Integration. Someone in the team is responsible for the combined Increment working.
• Knowledge. The company should understand what it is paying for. Dependency on a vendor's undocumented code is a risk.
• Quality. The Guide holds the Developers accountable for quality, and the team cannot delegate that.

Making it work

Bring the vendor into the events. Planning, the Daily Scrum, the Review and the Retrospective. A vendor who sees only a specification builds to the specification.

One backlog. The vendor's work appears on the same list as everyone's, with the same ordering.

Write the contract for the way you work. Short-term commitments, a right to change scope, regular checkpoints and a clear exit. The Wikipedia entry on outsourcing notes that it is the contracting out of a business process to an external provider, and the risks it names include loss of control and quality problems. See fixed-price contracts and Scrum.

Share the Definition of Done in writing. And review it together.

Use the same tools where possible. A shared board and repository remove a source of delay.

Keep a human link. One person on each side who talks every day. Trust matters more than contracts.

Inspect early and often. Ask for a working Increment each Sprint and not a report at the end.

Plan the handover. If the vendor leaves, the knowledge should stay.

A worked example

This is an illustrative case. A retailer is building a mobile app. It has a Scrum Team of five and engages a vendor for the payment integration, which needs a specialist.

First attempt: model three. The vendor is given a specification and a date, and works alone. After eight weeks it delivers. The app team finds that the interface differs from what was assumed, error handling is missing and the vendor's tests do not match the retailer's Definition of Done. Four weeks of rework follow.

Second attempt: model one. The vendor supplies two specialists who join the Scrum Team for the next phase. They attend every event, take items from the Sprint Backlog and follow the Definition of Done. The Product Owner orders the payment work with everything else. In the first Review the stakeholders see the payment flow working, with a rough edge, and request a change that is made in the next Sprint. The vendor's staff pair with the team's Developers, and the knowledge transfers as a by-product.

The contract changed from a fixed deliverable to a two-month renewable team supply. The retailer paid more per day and delivered earlier.

Common mistakes

• Treating the vendor as a black box. The first surprise is expensive.
• Letting the vendor's manager decide priorities. The Product Owner does.
• A contract that punishes change. It makes Scrum's adaptation a legal dispute.
• Two definitions of done.
• Handing over product knowledge entirely.
• Isolating vendor staff from team events and informal communication.
• Blaming the vendor for poor integration when the team never defined it.

How to practise it

For each vendor you use, write which of the three models applies and what would have to change to move one step closer to model one. In the simulator the Sponsor and stakeholders are external to the team, and keeping the Product Owner's authority over scope is a recurring theme.