Agile with an external development team: what the client side needs to do

Agile with an external development team works much like agile in-house, with one difference: the team can only build what you decide, as fast as you decide it. The external team runs the sprints. You own the backlog, the priorities and the final word on whether work is done. When outsourced agile projects stall, the cause is often on the client side, where answers arrive late or not at all.

Who does what

A good partner brings the delivery process: sprint planning, estimates, code review, testing and a demo at the end of each sprint. Our post on how a managed engineering squad works day to day describes that side. This post is about your side, which takes less time but can't be handed to anyone else.

• You own the product goal, the order of the backlog, answers to product questions and acceptance of finished work.
• The team owns how the work is built, the sprint plan within your priorities, code quality and raising risks early.

The product owner's job

Name one person on your side as product owner. The Scrum Guide is direct about this: the product owner is one person, not a committee. Others can advise, but one person must be able to say yes, no or not yet without waiting for a meeting. Their job is to:

• Set the product goal for the coming months and explain it to the team.
• Keep the backlog in order, with the most valuable work at the top.
• Write or approve acceptance criteria for each item before it enters a sprint.
• Answer the team's questions quickly, or find the person who can.
• Accept or reject finished work against those criteria.
• Say no to requests that don't serve the goal, and keep new work out of a sprint once it has started.

How much time the role takes

The role is a real part of someone's week, not a meeting on Friday afternoons. In every sprint, the product owner needs time for:

• Sprint planning at the start, to agree what goes in.
• Backlog refinement with the team, to get the next items ready before they are needed.
• Daily availability during shared working hours, to answer questions the same day.
• The sprint demo at the end, to see working software and give feedback.
• Acceptance testing, trying finished items soon after the team marks them done.

If nobody on your side has that time, fix it before the first sprint. A team that waits for answers either stops or guesses, and guessing is the more expensive of the two.

Each sprint event, from the client's side

Sprint planning

Bring the top of the backlog in order, with acceptance criteria written. The team brings estimates, risks and questions. Together you agree a sprint goal, one sentence on what the sprint should achieve, and the items that serve it. An item too vague to estimate isn't ready and should wait for the next sprint.

The daily stand-up

You don't need to attend every day. Ask the team to post any blocker that needs you in a shared channel, and answer it the same day. Our teams keep at least four hours of overlap with your working day, so most questions can be settled live.

The sprint review, or demo

This is the meeting that matters most for you. The Scrum Guide describes the review as a working session and warns against limiting it to a presentation. Use the software yourself, ask the team to show the edge cases, and bring the people who will use it if you can. Leave with a clear list of what is accepted, what needs changing and what goes back into the backlog.

The retrospective

The team looks at how it worked and picks one or two changes for the next sprint. Join part of it from time to time and ask for honest feedback about your side: late answers, unclear criteria, priorities that changed mid-sprint. Those are often the fixes that help the most.

How to give feedback the team can act on

• Give it on working software, in the demo or a test environment, not on screenshots in an email thread.
• Tie it to the acceptance criteria. 'The export leaves out archived invoices, which the criteria include' can be fixed. 'It doesn't feel right' can't.
• Separate bugs from new ideas. A bug means the item doesn't meet its criteria. A new idea becomes a new backlog item and is prioritised like any other.
• Write it down in the tracker, one issue per problem, with the steps to reproduce it.
• Give it soon. Feedback in the days after a demo is cheap to act on. Feedback weeks later means reopening work the team has moved past.
• Say what works, too. It tells the team which choices to repeat.

New ideas raised in demos are a common source of quiet scope growth. Our post on managing scope creep covers how to keep them visible without saying no to everything.

Common mistakes on the client side

• A product owner with no time. The role goes to someone already overloaded, and decisions wait for days.
• Too many voices. Several stakeholders give the team different directions. Route every request through the product owner.
• Changing priorities mid-sprint. Unless it is a real emergency, new work waits for the next planning session.
• Skipping the demo. Problems then surface near a deadline, when they cost the most to fix.
• Treating the backlog as a wish list. Hundreds of unordered items hide what matters. Keep the top of the backlog short and ready.
• Using agile to avoid a budget. Agile lets scope change, but the money is still finite. Agree how cost and scope will be tracked, whether the contract is fixed price or time and materials.
• Managing individuals instead of outcomes. Assigning tasks to specific developers cuts across the team's own planning and blurs who is accountable.

Where to start

Before the first sprint, name the product owner and clear room in their week. Put the next few weeks of work into an ordered backlog, with acceptance criteria for the top items. Agree the sprint length and the demo time, and put the demo in the calendars of the people who need to see it.

If you are choosing a team now, our managed engineering squads come with a squad lead who runs sprint planning, code reviews and progress updates, so your side can focus on priorities. Book a free 30-minute call to talk through how that would fit your product.