Delivery made predictable, answered in full.
- questions in this group, each answered in full
- 60
- pages the answers are written on, every one linked
- 4
- questions across the whole FAQ
- 1424
60 questions on delivery made predictable, answered by Tenhaw, a UK AI consultancy and AI delivery partner based in London. Nothing here is a summary: each answer is the exact text from the page that owns it, and every group links back to that page for the context around it.
Discovery
Answered on Discovery, and rendered here in the same words.
Read the page these answers live on →
Was the Discovery+ launch a Tenhaw engagement or James's own role?
James's own role, not an engagement delivered under the Tenhaw banner. It was one of James Rooney's delivery and transformation roles, and he ran the visual rebrand team on the Discovery+ launch for ten months, one of six development teams working to a launch date the CEO had announced. The case study sits on tenhaw.com because the discipline it demonstrates is the one Tenhaw installs today, probabilistic forecasting that leadership can plan and intervene against. We are always clear about which engagements were the founder's roles and which were Tenhaw's, and will walk you through which is which on a call.
How do you hit a launch date the CEO has already announced?
By making the risk of missing it visible early enough to act on. On the Discovery+ launch, six development teams had to redesign and merge content for a date announced by the CEO, and the visual rebrand team was badly overloaded relative to the time available. Delivery moved onto a data-driven footing. Story Points were recalibrated to reflect actual capacity, three sprints of Happy, Normal and Sad path forecasts made the probability of missing the date undeniable, and daily recommendations lifted speed and quality. The launch hit its date on both Discovery+ and Eurosport.
What are Happy, Normal and Sad path forecasts?
Three delivery scenarios put side by side: what happens if everything goes well, what happens at the pace the data says is normal, and what happens if it does not. On the Discovery+ launch these went to the Head of Delivery across three sprints, built on Story Points recalibrated to actual capacity. Together they made the probability of missing the CEO's announced date undeniable. That is what leadership needs. Not a single guessed date, but a range of outcomes it can plan and intervene against.
Does telling leadership a launch will probably miss backfire?
Not when the forecast is built on measurement. On the Discovery+ launch, three sprints of scenario forecasts made the probability of missing the CEO's date undeniable, and what came back was clarity, not blame. Discovery+ and Eurosport could finally manage delivery under real constraints, and the six-team launch hit its date. What backfires is the alternative, a single optimistic date defended until it collapses. A forecast presented as a range gives leadership time and options to intervene while intervening can still change the outcome.
Why adjust Story Point estimates after the work is completed?
Because estimates made under deadline pressure drift optimistic, and forecasts built on optimism are fiction. On the Discovery+ launch the fix was to recalibrate Story Points after completion, so they reflected the capacity each team had actually demonstrated and not the capacity everyone hoped for. That recalibration is what made the Happy, Normal and Sad path forecasts credible enough to act on. They were grounded in what the teams had really done, sprint after sprint. Once the numbers reflected reality, the conversation about the launch date could too.
What do you do when one team is the bottleneck on a big launch?
First make the overload a measured fact instead of a feeling. On the Discovery+ launch, the visual rebrand team James ran was badly overloaded relative to the time available, one of six teams working to a fixed date. Recalibrating Story Points after completion, so they reflected the capacity the team had actually demonstrated, turned that overload into numbers nobody could argue with. Once the constraint was measurable, the Happy, Normal and Sad path forecasts kept its consequences in front of the Head of Delivery sprint by sprint. Daily recommendations worked the problem from the other end by lifting speed and quality.
Did the Discovery teams learn to run the forecasting themselves?
Yes. By the end of the ten-month engagement both the Discovery+ and Eurosport teams could run the forecasting and tracking practices autonomously, without James in the room. That was deliberate, not a side effect. The point of making delivery risk visible is that the client's own people keep doing it once you leave. It is the same standard Tenhaw holds today under the built to leave principle, and the forecasting method itself is published free in The Tenhaw Way, so nothing about it depends on a consultant staying.
Why does probabilistic forecasting matter for an AI transformation?
Governing an agentic transformation needs what governing the Discovery+ launch needed. Leadership does not want a single guessed date. It wants a range of outcomes it can plan and intervene against. Probabilistic forecasts and confidence intervals tell an executive how likely a programme is to land where it is pointed, early enough to change course instead of holding an inquest. The method carries over intact, because it never depended on what was being delivered. On the Discovery+ launch it turned an overloaded team's demonstrated capacity into three sprints of scenario forecasts the Head of Delivery could act on, and both platforms hit the date.
How long does it take before leadership trusts a delivery forecast?
On the Discovery+ launch, three sprints. That was the gap between putting delivery on a data-driven footing and forecasts that made the probability of missing the launch date undeniable to the Head of Delivery. The credibility came from the inputs. Story Points were recalibrated after completion to reflect actual capacity, so every forecast was built on what the teams had demonstrably done and not on what they had promised. Trust in a forecast is really trust in its data, and three sprints of honest numbers was enough to change how a six-team launch was governed.
Are daily delivery recommendations overkill under a hard deadline?
No. A hard deadline is when waiting a week between course corrections costs the most. On the Discovery+ launch, daily recommendations to lift speed and quality ran alongside the sprint-level forecasts, so the teams always had something specific to change while there was still time for the change to matter. The forecasts told leadership where the launch was heading, and the daily recommendations were the mechanism for bending that trajectory. Delivery risk made visible early enough to act on it is what made the difference, and a six-team launch hit its date.
Does hitting a fixed launch date always cost quality?
It does not have to. It usually does when the squeeze only becomes visible in the last fortnight. On the Discovery+ launch, six development teams had to redesign and merge content for a date the CEO had announced, and the visual rebrand team was badly overloaded relative to the time available. The daily recommendations issued to those teams covered speed and quality together, not speed alone, and they were useful because the pressure showed up early. Story Points recalibrated after completion exposed the real capacity, and three sprints of Happy, Normal and Sad path forecasts put the consequences in front of the Head of Delivery while there was still room to act. Both Discovery+ and Eurosport hit the date.
Does delivery forecasting work for design and content teams?
Yes, and the Discovery+ launch is the case in point. James ran the visual rebrand team for ten months, one of six development teams whose job was to redesign and merge content across Discovery+ and Eurosport. The method does not depend on what the work product is. Story Points were recalibrated after completion to reflect the capacity a team had actually demonstrated, and that measures design and content output as readily as it measures code. The Happy, Normal and Sad path forecasts built on those numbers were credible enough to change how the launch was governed. Both platforms hit the date.
Who needs to see a delivery forecast for it to change anything?
Whoever can move something. On the Discovery+ launch that was the Head of Delivery, who saw Happy, Normal and Sad path forecasts across three sprints, because that was the person who could act on constraints sitting across six teams rather than inside one. A forecast that reaches people with no levers becomes a report, while a forecast in front of someone who can intervene becomes a decision. The teams themselves needed the same information in a different form and got it, as daily recommendations to lift speed and quality. That is something a team can use the next morning, while the date is still reachable.
Won't teams game their estimates once forecasts drive decisions?
The incentive to shade a number largely goes away when nobody is being asked to bid one. On the Discovery+ launch every forecast took its input from measurement after the work, Story Points recalibrated to the capacity a team had already demonstrated, so there was nothing to inflate in advance. The other half of it is what the numbers were used for. When three sprints of Happy, Normal and Sad path forecasts showed the visual rebrand team was badly overloaded relative to the time available, the response was daily recommendations to lift speed and quality rather than an inquest. People defend themselves against measures used against them, and rarely bother with one that gets them help.
Should a delivery lead run the team or advise from the outside?
On the Discovery+ launch it was both, and the combination is what made it work. James was asked to run the visual rebrand team, one of six development teams on the launch, so the delivery data came from inside a badly overloaded team rather than from a spreadsheet passed around at a distance. At the same time the Happy, Normal and Sad path forecasts went to the Head of Delivery, because that is where the picture had to land for anything to change. Advice from outside a team rarely survives contact with the sprint, and running a team with no route to leadership means carrying the bad news alone.
If the sources do not answer it, a call will.
Talk it throughGreggs
Answered on Greggs, and rendered here in the same words.
Read the page these answers live on →
What did Tenhaw actually deliver at Greggs?
Scrum Master support for two squads, Mobile App and Integration, plus agile coaching across the wider business, over six months. Greggs had launched a mobile app so customers could order and earn rewards, but the rushed setup of technical ways of working created friction with Marketing and other departments. We refined Story Points so tracking followed real capacity. Product was coached to prioritise from data, and the workshops and alignment sessions we ran taught non-technical teams how agile actually works. By the end delivery was predictable and prioritisation conversations were realistic, and confidence in the technical department had recovered.
What has coaching a delivery team got to do with agentic change?
More than it looks. This was Scrum Master support for two squads and agile coaching across the wider business, and the preconditions it built are the ones agentic change depends on. Agents amplify whatever operating culture they land in, so cross-functional trust and a shared, data-backed language for value have to be sound before automation arrives. Six months bought Greggs predictable delivery. It also bought prioritisation conversations that were realistic and focused, and a technical department the rest of the business trusted again.
Did Tenhaw exist when the Greggs work was delivered?
Some of the work on this site predates the company, and we are straightforward about which. Greggs sits in the group of engagements delivered under the Tenhaw banner, alongside Anglo American, Yondr, Colart, Tecknuovo and Globelynx. Several in that group predate incorporation and were delivered by James Rooney personally on contract, and we will walk you through which is which on a call. The distinction matters more for the paperwork than for the work. Tenhaw is founder-led, James leads every engagement personally, and the six months of Scrum Master support and coaching described in this study happened as written, whichever banner it sat under.
How do you rebuild trust between a technical team and the rest of the business?
By making delivery predictable enough that commitments mean something again. At Greggs the problem was never technical. An app team had been stood up at speed during the pandemic, ways of working were invented on the way, and the friction with Marketing and other departments had eroded confidence in the whole technical department. We rebuilt the numbers first, refining Story Points so tracking reflected real capacity, then ran alignment sessions and prioritisation workshops that put those numbers in front of the other departments. Trust followed the data. Once delivery became predictable, prioritisation conversations turned realistic and focused, and confidence in the technical department recovered.
How do you prove paying down tech debt speeds up delivery?
Use the delivery data. The claim that paying down tech debt speeds up delivery is usually made as a technical argument and lost as a budget conversation, because nobody outside engineering can weigh an engineer's opinion. At Greggs we used delivery data to prove the payback of addressing tech debt, and the numbers are what let the argument survive contact with Marketing and the other departments. The data showing tech debt work accelerated timelines strengthened collaboration across the departments. The wider lesson is that a shared, data-backed language for value turns the hardest prioritisation arguments into something every department can judge on the same terms.
Why do rushed app launches cause delivery problems later?
Because ways of working invented under pressure harden into the operating model. Greggs stood its app team up at speed so customers could order and earn rewards, and the rushed setup created friction with Marketing and other departments. The pattern recurs, and it is not a technical one. A team ships under pressure, estimates stop being believed, then prioritisation turns into a negotiation about credibility rather than value. At Greggs it took a six-month engagement of capacity-based tracking and coaching that reached beyond engineering to make delivery predictable and the department trusted again.
Does agile coaching work outside engineering teams?
Yes, and at Greggs coaching beyond engineering was a stated part of the brief, not a side effect. Alongside Scrum Master support for the Mobile App and Integration squads, we ran prioritisation workshops and alignment sessions that showed non-technical teams how agile actually works. The point was never to make Marketing run stand-ups; it was to give every department a shared, realistic picture of capacity, so conversations about what gets built next start from data rather than assertion. That organisation-wide coaching is a large part of why predictable delivery turned into recovered trust across departments.
Why does team credibility matter before starting an AI programme?
Because a department whose commitments are not believed cannot sequence anything, including an AI programme. A head of AI inheriting a distrusted technical department will find the blocker is not the model. It is that no estimate the department makes is taken seriously, so nothing can be planned against. The Greggs engagement is what fixing that looks like. Six months of Scrum Master support and coaching made delivery predictable and made the department's numbers believable again. An AI programme gets planned against those numbers like everything else, so they have to be believable before the technology arrives.
What would a Greggs-style engagement cost from Tenhaw today?
It would be sold as Programme and Delivery Management at £18k–£35k per month, depending on scope. The Greggs work, Scrum Master support across two squads plus agile coaching beyond engineering, sits squarely in that service. What you are buying is senior delivery leadership that makes output predictable and gives the business numbers it can plan against. Tenhaw engagements are retainer-shaped with an exit date agreed at kickoff and 30 days' notice either side, and a month that delivers no measurable value is reported as a failed month. A 30-minute call is the quickest way to size your version of it.
How do you get prioritisation decisions based on value rather than politics?
Give every side the same numbers and coach them to argue from them. At Greggs, friction between the technical department and Marketing meant prioritisation ran on assertion. Refining Story Points for capacity-based tracking rebuilt the numbers, Product was coached to prioritise from data, and the prioritisation workshops and alignment sessions put that evidence in front of every department at once. That is the shift the study records. Prioritisation conversations became realistic and focused, and even the hardest sell, spending delivery time on tech debt, was won with delivery data rather than opinion. Shared numbers that everyone believes leave politics very little to work with.
Does retail tech debt have to be paid down before AI modernisation?
Not all of it, and the real decision is which parts. Pay down the retail tech debt that sits directly in the path of the work you intend to automate, and keep the rest costed and visible. Tech debt and an AI modernisation programme draw on the same delivery capacity, so it gets settled as a budget question and not an engineering one. At Greggs we used delivery data to show that tackling tech debt accelerated timelines, which gave Marketing and the other departments a shared basis for agreeing the order of work. That same data lets you sequence modernisation around the debt that actually blocks it. Clearing the lot first is rarely the cheapest route.
Is our delivery problem the team or the way they work?
Usually it is the way they work. Greggs shows the difference clearly. The app team was stood up at speed so customers could order and earn rewards, and it was the rushed setup of technical ways of working, not the engineering, that created friction with Marketing and other departments. The tell is where the disbelief sits. One team missing its own dates is a team problem. Several departments no longer believing any estimate is an operating model problem, and more pressure on the team will not shift it. What made delivery predictable again was six months of Scrum Master support and capacity-based tracking, with coaching that reached beyond engineering.
Should Marketing be in the prioritisation workshop, or just Product?
Both, and at Greggs that was rather the point. Product was coached to prioritise from data, but the friction sat between the technical department and Marketing, so a workshop with only Product in it would have moved the argument rather than settled it. We ran prioritisation workshops and alignment sessions together, the sessions teaching non-technical teams how agile actually works so everyone in the room could read the capacity numbers. Once the people asking for work and the people doing it were looking at the same figures, prioritisation became a choice between options instead of a test of anyone's credibility.
What happens if the delivery data makes the team look bad?
It often does at first. What you do with that first honest picture decides the engagement. Capacity-based tracking replaces optimistic estimates with what the team has actually demonstrated, so the early numbers tend to be smaller than what the business believed it had been promised. At Greggs the refined Story Points went straight into prioritisation workshops with Marketing and the other departments. They were the basis for deciding what came next, not a scorecard for what had gone before, and confidence in the technical department recovered. Used as a stick, the same data destroys the trust it was gathered to rebuild.
How do you tell whether agile coaching actually worked?
By what changes outside the team, not by how the ceremonies feel. Ask whether what the team forecasts matches what lands. Ask whether other departments plan against those numbers, and whether the arguments have moved from credibility to value. Greggs is what passing looks like. After six months of refined Story Points and capacity-based tracking, delivery was predictable and prioritisation conversations were realistic and focused, and confidence in the technical department had recovered. We hold our own engagements to the same standard. They are retainer-shaped, and a month that delivers no measurable value is reported as a failed month.
If the sources do not answer it, a call will.
Talk it throughColart
Answered on Colart, and rendered here in the same words.
Read the page these answers live on →
What did Tenhaw do for Colart?
Over six months we turned three newly merged teams, Global Marketing, Development and Business Intelligence, into one working Digital Team. The work was process and workflow design: agile processes built for a cross-functional team, Jira workflows aligned to how the business actually worked, clear communication channels, a matured backlog that cut downtime, and data-guided prioritisation, with critical issues escalated to senior leadership when needed. The result was a cohesive, predictable team, transformation work that progressed consistently, and an e-commerce website that shipped successfully. The discipline behind that, one agreed definition of a finished piece of work and one route for moving it, is what turned three merged functions into a single delivery unit.
Why do merged teams stop delivering after a reorganisation?
Because the merger creates a team on the org chart before it creates one in practice. When Colart merged its Global Marketing, Development and Business Intelligence teams, the new Digital Team had no shared alignment, no established communication channels and no consistent way of delivering, and key transformation work stalled, including a new e-commerce site. Nobody in that situation is underperforming individually. The connective tissue is missing. So the fix at Colart was structural, not motivational. We agreed processes for the cross-functional team, matched workflows to the real work, made the communication channels explicit, and gave the team a route to senior leadership for the issues it could not resolve itself.
Can agile work across marketing, development and business intelligence teams?
Yes, when the process is designed for the mixed team rather than borrowed from software engineering and imposed on everyone else. At Colart the new Digital Team combined Global Marketing, Development and Business Intelligence, and we designed agile processes for that cross-functional shape, with Jira workflows aligned to how the business actually worked. Clear communication channels and data-guided prioritisation did the rest. The team became cohesive and predictable, and the stalled e-commerce website shipped successfully.
Is it worth redesigning Jira workflows around how the business works?
It was at Colart. A workflow that mirrors how work actually moves through the business gets used honestly; one that mirrors a tool's defaults gets worked around, and the board stops telling the truth about delivery. We aligned Colart's Jira workflows to how the newly merged Digital Team really operated, as part of a wider redesign covering agile processes, communication channels and a matured backlog. Delivery became consistent enough that the stalled e-commerce build progressed and shipped. The workflow itself is not the point; it is the state model that makes a piece of work unambiguous, and that is what the merged team had been missing.
How does a mature backlog reduce downtime?
A matured backlog means the next piece of work is already defined, understood and ready when the team finishes the current one, so nobody idles while requirements are chased or decisions are awaited. At Colart, maturing the backlog was one of the specific levers we used, and less downtime is the result the study records. It matters most in a newly merged team, because the person who used to answer a quick question across the desk may now sit in a different part of the organisation, and every ill-defined item turns into a wait. Combined with data-guided prioritisation, it kept Colart's Digital Team delivering consistently.
How do you prioritise when newly merged teams disagree?
Data settled it. Three merged teams arrived at Colart with their own views of what mattered, so we used data to guide prioritisation and the backlog began reflecting evidence instead of whichever function argued loudest. Two other mechanisms mattered alongside it. A matured backlog meant every item was well enough defined to be compared honestly. A clear escalation route meant the critical issues the team could not settle went to senior leadership before they festered. Prioritisation disputes are usually a symptom of missing structure. The people are rarely the problem. Once the structure existed, Colart's Digital Team delivered predictably.
How long does it take to align merged teams into one delivery unit?
At Colart it took six months to take three merged teams, Global Marketing, Development and Business Intelligence, from stalled and misaligned to cohesive and predictable, with the e-commerce website shipped along the way. Most of that time went into design work. We shaped agile processes for a cross-functional team, matched the Jira workflows to the real work, set up communication channels people actually used, and matured the backlog to the point where downtime fell. The honest caveat is that six months describes this organisation, not every merger. The pattern transfers. The number is theirs.
Did Colart's e-commerce platform actually ship?
Yes. The e-commerce website was among the key transformation work that stalled while Colart's merged Digital Team lacked alignment and consistent delivery, and it shipped successfully once the team was working as one unit. The causal chain is worth being clear about. We designed the processes, Jira workflows and communication channels that let the merged team build the platform, and Colart's own engineers built it. That distinction is one to check in any consultancy's case studies. The delivery discipline was ours. The engineering was Colart's own people, unblocked.
What does a workflow design engagement have to do with agentic AI?
More than it first appears. An AI agent needs the same things Colart's merged team needed. It has to know what a piece of work is, how to move it through a state model, and where to escalate when it cannot proceed. Design those well for people and you have designed most of what an agentic operating model needs later. Colart is what that groundwork looks like in practice. Three merged functions ran off a single backlog and a single state model, and a stalled e-commerce site shipped once the team worked as one unit.
Was the Colart work delivered by Tenhaw or by James personally?
Colart is one of the engagements delivered under the Tenhaw banner, alongside Anglo American, Yondr, Greggs, Tecknuovo and Globelynx. Several of those predate the company's incorporation and were delivered by James Rooney personally on contract, and we will walk you through which is which on a call rather than blur the line in marketing copy. The delivery experience is the same either way, because James leads every Tenhaw engagement personally today. We keep this separate from the HSBC, Microsoft, Sky, F1 and Discovery track record, which were the founder's delivery and transformation roles inside those organisations.
Does a retail AI operating model start with the team or the technology?
With the team. A retail AI operating model is mostly a set of agreements about how work is defined and moved between functions, and Colart is the pre-AI version of that argument. When Global Marketing, Development and Business Intelligence merged into one Digital Team, the team had no shared alignment, no established communication channels and no consistent way of delivering, and a new e-commerce site stalled. Six months of process, Jira workflow and backlog design made it cohesive and predictable, and the site shipped. If those three functions cannot agree today what a finished piece of work looks like, no agent will settle it for them.
Can't our own delivery managers fix a stalled merged team?
Often, yes. If leadership is aligned and the merged functions already trust one way of working, run it in-house and keep the fee. It gets harder when the shape of the merger is the problem. Colart's new Digital Team combined Global Marketing, Development and Business Intelligence, and a process shaped around any one of those sets of habits tends to be quietly ignored by the other two, so whoever designs it has to work for the mixed team without belonging to a part of it. That took six months at Colart, alongside a standing route to senior leadership for the calls the team could not make itself. If your own managers can hold both, you do not need us.
What if senior leaders ignore the issues a team escalates?
Then the escalation route is decoration, and no amount of workflow design compensates for it. Escalating critical issues to senior leadership was one of the named mechanisms at Colart, and it only counts as a mechanism if somebody answers. A team that raises a blocker and hears nothing learns to stop raising blockers, so the risk log goes quiet while the risks carry on. Test it before you design around it. Take one properly blocked item, escalate it, and time how long a decision takes. If the answer is never, that is the thing to fix first, and no board redesign will hide it.
What does fixing a team's communication channels actually involve?
Less than a governance framework and more than a new chat channel. Colart's merged Digital Team spanned Global Marketing, Development and Business Intelligence, and making its channels explicit meant agreeing where each kind of request or decision gets raised, who the three functions go to for what, and where critical issues go when the team cannot settle them itself, which at Colart was senior leadership. A merger quietly removes the informal routes people relied on before anyone notices they have gone. The symptoms then look like poor delivery rather than poor plumbing. It was one of the levers that got the stalled e-commerce work moving again.
How do you stop merged teams quietly re-forming as silos?
Make them share the artefacts, not just the org chart. Three functions can sit in one Jira project and still run three processes, so at Colart the shared layer was designed deliberately: agile processes built for the cross-functional team rather than lifted from one function's habits, Jira workflows aligned to how the business actually worked, and one backlog the whole Digital Team drew its next piece of work from. Silos re-form through small defaults, a separate board here, a private thread there, and the way to stop that is to leave nowhere sensible for those defaults to live. Six months in, the team was predictable and the e-commerce site had shipped.
If the sources do not answer it, a call will.
Talk it throughYOOX NET-A-PORTER
Answered on YOOX NET-A-PORTER, and rendered here in the same words.
Read the page these answers live on →
What did Tenhaw do at YOOX NET-A-PORTER?
We provided the Scrum Master and PMO backbone on a £1bn programme re-platforming YNAP's e-commerce solution to IBM WebSphere Commerce, delivered by Salmon. Over 12 months we coordinated five agile teams against strict client deadlines: facilitating agile delivery, managing onboarding logistics and equipment, streamlining communication between the client PMO and the delivery teams, and maintaining transparency through weekly reporting. The teams met their deadlines with a high standard of collaboration, and the programme closed with strong client satisfaction. Tight operational processes are what held that together across five parallel teams.
How do you coordinate five agile teams on one programme?
With one operating rhythm everyone trusts and a single source of truth about the state of the work. On YNAP's £1bn re-platform we ran a dual Scrum Master and PMO model. Agile facilitation sat inside the teams so each kept its cadence, and a PMO layer above them owned reporting, dependencies and operational logistics. Communication between the client PMO and the delivery teams was streamlined, so questions had one route in and answers had one route out, and weekly reporting kept the whole programme transparent. Five teams met strict client deadlines for 12 months on that footing.
Do agile programmes still need a PMO?
At scale, yes, and YNAP is the evidence. Five agile teams inside a £1bn re-platform each had their own cadence, but somebody still had to hold the cross-team picture. That meant dependencies, onboarding logistics, equipment, travel, and one version of progress the client PMO could trust. We ran Scrum Master and PMO as a dual model, not as rivals. Agile facilitation gave the teams their rhythm and the PMO gave the programme its transparency through weekly reporting. Teams met their deadlines and collaboration stayed strong. That is what a PMO is actually for.
How big was the YNAP re-platforming programme?
It was a £1bn programme, with five agile teams coordinated through a 12-month Scrum Master and PMO engagement. Salmon was re-platforming YOOX NET-A-PORTER's e-commerce solution to IBM WebSphere Commerce, and the scale demanded tight coordination against strict client deadlines while staff transitions and operational logistics were managed in parallel. Streamlined communication, weekly reporting and one operating rhythm across all five teams kept it aligned, because alignment is the constraint at that size. The programme met its deadlines with strong client satisfaction.
What platform did YNAP move its e-commerce to?
IBM WebSphere Commerce. Salmon delivered the re-platform of YOOX NET-A-PORTER's e-commerce solution, and we provided the Scrum Master and PMO backbone that kept five agile teams aligned to the client's deadlines across 12 months. Our part was delivery coordination. We facilitated agile delivery inside the teams, streamlined communication between the client PMO and the internal teams, and maintained transparency through weekly reporting, with onboarding logistics and equipment handled centrally so the teams kept their hours for delivery. The programme progressed efficiently and met its deadlines.
What does a £1bn re-platform have to do with agentic AI?
The coordination problem is the same. Multi-team delivery with a single source of truth, many actors, shared dependencies and one operating rhythm everyone trusts is what agentic transformation faces at scale, just with agents among the actors. The YNAP engagement proved that discipline across five teams on a £1bn programme. What it took was one operating rhythm the five teams shared, a single route for questions between the client PMO and the delivery teams, and weekly reporting nobody had to reconcile. Dependencies were handled before they turned into missed dates, and the teams held strict client deadlines for 12 months.
How do you keep a client PMO and supplier delivery teams aligned?
By giving communication one spine instead of many threads. On the YNAP re-platform, Salmon's five agile teams delivered against YOOX NET-A-PORTER's strict deadlines, and we sat in the middle: streamlining communication between the client PMO and the internal teams, maintaining transparency through weekly reporting, and coordinating the operational detail (onboarding, equipment and travel) that otherwise leaks into delivery time. When both sides trust the same version of progress, escalations get faster and surprises get rarer. The teams met their deadlines and the client's satisfaction was strong.
How do you keep a programme moving through staff changes?
Treat transitions as an operational discipline. The YNAP re-platform ran for 12 months across five agile teams, and staff transitions were part of the terrain, so we managed onboarding logistics and equipment centrally. A new joiner arrived to a working setup and a clear picture of the programme, not a fortnight of finding their feet. Weekly reporting and streamlined communication with the client PMO did the rest, and delivery stayed efficient enough to meet strict client deadlines throughout.
Do you have large-scale e-commerce delivery experience?
Yes. We spent 12 months providing the Scrum Master and PMO backbone on YOOX NET-A-PORTER's £1bn re-platform to IBM WebSphere Commerce, coordinating five agile teams against strict client deadlines that were met. That is e-commerce delivery at serious scale. Staff transitions, onboarding logistics, equipment and travel were handled centrally, communication between the client PMO and the delivery teams ran through one streamlined route, and progress stayed transparent through weekly reporting. The programme closed with strong client satisfaction, which at that size is a statement about coordination more than about any one team.
Did the YNAP re-platform hit its deadlines?
They did. The teams met the client's deadlines with a high standard of collaboration, and tight operational processes produced a well-executed project and strong client satisfaction. At £1bn scale that is not luck. Five agile teams shared one operating rhythm, communication between the client PMO and the delivery teams ran through a single streamlined channel, and weekly reporting kept progress transparent enough that problems surfaced while they were still cheap. Deadlines hold when coordination is somebody's actual job. That is what the 12-month Scrum Master and PMO engagement existed to do.
Does a retail AI operating model have to cover our delivery partners?
If a partner does the building, yes. A retail AI operating model that stops at your own org chart leaves the busiest seam in the programme undesigned, because decisions, dependencies and reporting all have to cross it anyway. YOOX NET-A-PORTER's £1bn e-commerce re-platform was delivered by Salmon across five agile teams, and the coordination backbone was scoped to cover both sides of that boundary rather than the client's side alone. Across 12 months the teams met strict client deadlines and the programme closed with strong client satisfaction. Agents change who does the work, not who has to agree the picture.
What does a PMO take off a delivery team's plate?
Everything that keeps the programme running but does not build anything. On YOOX NET-A-PORTER's £1bn re-platform the PMO layer above the five agile teams owned cross-team dependencies, onboarding logistics, equipment and travel coordination, so a team's own hours went into delivery. Nobody on those teams was chasing kit for a new joiner or assembling a status pack. Weekly reporting came from that layer too, and the client PMO saw one version of progress instead of five. The teams met strict client deadlines across 12 months on that split. Where nobody owns that work, five teams end up doing it badly in the margins.
What breaks first when a programme grows past two or three teams?
The shared picture, long before the code does. Two teams keep each other honest in a corridor. At five, on something the size of YOOX NET-A-PORTER's £1bn re-platform, dependencies surface late, each team reports progress in its own dialect, and a question to the client takes a different route every time. Nothing looks broken from inside a team, so it tends to get found at a deadline. That is why coordination on that programme was a dedicated Scrum Master and PMO job for 12 months rather than something five team leads squeezed in, and the teams met their deadlines with strong client satisfaction at the close.
Do five agile teams all need the same sprint cadence?
No, and forcing it usually solves the wrong problem. On YOOX NET-A-PORTER's £1bn re-platform each of the five agile teams kept its own cadence, because agile facilitation sat inside the teams while the PMO layer above them owned reporting and dependencies. What has to be common is the reporting rhythm and the definition of progress, so the client PMO sees one version of the programme rather than five partial ones. Weekly reporting did that job for 12 months and the teams met strict client deadlines throughout. The alignment that matters sits in the reporting layer, not in a shared sprint calendar.
If the sources do not answer it, a call will.
Talk it through1424 questions, grouped by subject
Every question answered anywhere on tenhaw.com sits in one of 51 groups. This is one of them.
All 1424questions, and every group →
Or ask the question directly and skip the categories.
Talk it throughStill have a question?
A 30-minute discovery call with James Rooney. Bring the question this page did not answer. You'll leave with a rough scope whether you engage us or not.
most start with a fixed-price AI Readiness Audit · £44,000 · 4 weeks · working prototypes
Calendar not loading? Open it on cal.com or email hello@tenhaw.com.