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
- 1293
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?
It was one of James Rooney's delivery and transformation roles rather than an engagement delivered under the Tenhaw banner. James 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, probabilistic forecasting that leadership can plan and intervene against, is the same one Tenhaw installs today. 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 presented 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 were presented to the Head of Delivery across three sprints, built on Story Points recalibrated to actual capacity rather than optimistic estimates. Together they made the probability of missing the CEO's announced date undeniable, which is precisely 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 message is data rather than opinion. On the Discovery+ launch, three sprints of scenario forecasts made the probability of missing the CEO's date undeniable, and the result was not blame but clarity: 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 to reflect the capacity each team actually demonstrated, 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 rather than 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, to reflect the capacity the team actually demonstrated rather than optimistic estimates, 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, and 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 a deliberate outcome rather than 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?
Because governing an agentic transformation needs exactly what governing the Discovery+ launch needed: not a single guessed date, but a range of outcomes leadership 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 rather than hold an inquest. On the agentic side this case study claims nothing more: there were no agents on the Discovery+ engagement, and the forecasting method is the only thing that carries over. It carries over completely, because the method never depended on what was being delivered.
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 recalibrated after completion to reflect actual capacity, so every forecast was built on what the teams had demonstrably done rather than 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 exactly 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; the daily recommendations were the mechanism for bending that trajectory. That is what made the difference: delivery risk made visible early enough to act on it, and a six-team launch that hit its date.
Does hitting a fixed launch date always cost quality?
No, though 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 rather than 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, which measures design and content output as readily as it measures code, and 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, which is what 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 the input to every forecast was measured 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, which 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.
Book thirty minutesGreggs
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 for capacity-based tracking, coached Product on data-driven prioritisation, and ran workshops and alignment sessions that taught non-technical teams how agile actually works. By the end, delivery was predictable, prioritisation conversations were realistic, and confidence in the technical department had recovered.
Was the Greggs engagement an AI project?
No, and the case study says so plainly: this was Scrum Master support and agile coaching, with no models and no agents anywhere in the deliverable. It sits on an AI consultancy's site because 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. Tenhaw labels every engagement this way: AI work is described as AI work, pilots as pilots, and delivery coaching as exactly that.
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 for paperwork more than for the work itself: Tenhaw is founder-led, James leads every engagement personally, and the six months of Scrum Master support and coaching described in this study happened exactly 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 not 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?
With data rather than engineering opinion. 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 it. 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 rather than hardening positions. That is the wider lesson of the engagement: 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 recurring pattern is not technical: a team ships under pressure, estimates stop being believed, and prioritisation becomes a negotiation about credibility rather than about 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 that made delivery predictable and made the department's numbers believable again. Agents amplify whatever operating culture they land in, so the culture has to be sound 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: 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 rather than evidence. Refining Story Points for capacity-based tracking rebuilt the numbers, Product was coached to prioritise from data, and prioritisation workshops and alignment sessions put that evidence in front of every department at once. The outcome the study records is exactly this shift: 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 rather than invisible. Tech debt and an AI modernisation programme draw on the same delivery capacity, so it gets settled as a budget question rather than 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 engagement was coaching and prioritisation, with no AI in it.
Is our delivery problem the team or the way they work?
Usually the way they work, and 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. Six months of Scrum Master support, capacity-based tracking and coaching beyond engineering is what made delivery predictable again.
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, and 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, as the basis for deciding what came next rather than as 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. Three checks: does what the team forecasts match what lands, do other departments plan against those numbers, and have the arguments 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, 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.
Book thirty minutesColart
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. There is no AI in this engagement; it is on the site because delivery discipline is the layer agentic work is installed on top of.
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. The fix at Colart was structural rather than motivational: agreed processes for the cross-functional team, workflows matched to the real work, explicit communication channels, and a route to senior leadership for the issues the team 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 specifically for that cross-functional shape, with Jira workflows aligned to how the business actually worked rather than to a tool's defaults. 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?
With data rather than with volume. At Colart, three merged teams arrived with their own views of what mattered, and we used data to guide prioritisation so the backlog reflected evidence rather than whichever function argued loudest. Two other mechanisms mattered alongside it: a matured backlog, so every item was well enough defined to be compared honestly, and a clear escalation route, so critical issues the team could not settle went to senior leadership instead of festering. Prioritisation disputes are usually a symptom of missing structure rather than difficult people, and 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. The time went into design rather than ceremony: agile processes shaped for a cross-functional team, Jira workflows matched to the real work, communication channels people actually used, and a backlog matured 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 study is deliberate about the causal chain: we did not build the platform, we designed the processes, Jira workflows and communication channels that let the merged team build it. That distinction is worth checking 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 exactly what Colart's merged team needed: an unambiguous definition of a piece of work, a state model to move it through, and somewhere to escalate when it cannot proceed. Design those well for people and you have designed most of what an agentic operating model needs later. What does not transfer is the technology, and the study says so plainly: this was process, workflow and backlog design, with no AI anywhere in the deliverable. We publish it because delivery discipline is the foundation agentic transformation is installed on, not because it is an AI credential.
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: 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. There was no AI anywhere in that deliverable. 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 genuinely 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?
More than opening a chat channel, less than a governance framework. 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, and the symptoms 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.
Book thirty minutesYOOX 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. It was a delivery and coordination engagement, not an AI one, and the case study says so plainly.
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 inside the teams so each kept its cadence, and a PMO layer above them that 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: 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 rather than as rivals, agile facilitation giving the teams their rhythm and the PMO giving the programme its transparency through weekly reporting. Teams met their deadlines and collaboration stayed strong, which is what a PMO is actually for.
How big was the YNAP re-platforming programme?
£1bn, 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. The engagement was built around streamlined communication, weekly reporting and one operating rhythm across all five teams, because at that scale alignment is the constraint, and 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 role was delivery coordination rather than platform engineering: facilitating agile delivery, streamlining communication between the client PMO and the internal teams, and maintaining transparency through weekly reporting. 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 exactly 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 does not transfer is anything agentic: this was a Scrum Master and PMO engagement on an e-commerce re-platform, and the study labels it that way. Tenhaw's case studies separate delivery track record from AI engineering deliberately, so you can see which claim rests on which evidence.
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 rather than an interruption. 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 rather than a fortnight of finding their feet. Combined with weekly reporting and streamlined communication with the client PMO, that kept delivery 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 handled centrally, communication between the client PMO and the delivery teams run through one streamlined route, and progress kept transparent through weekly reporting. The study sits in our track record as delivery and coordination work rather than AI, and it is labelled that way deliberately; the agentic evidence on this site has its own case studies.
Did the YNAP re-platform hit its deadlines?
Yes. 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. That was not luck at £1bn scale: 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, which 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. That engagement was Scrum Master and PMO work with no AI in it, and the study says so plainly.
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 rather than into chasing kit for a new joiner or assembling a status pack. Weekly reporting came from that layer too, which is why the client PMO could see 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, which is why it tends to get found at a deadline instead. 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.
Book thirty minutes1293 questions, grouped by subject
Every question answered anywhere on tenhaw.com sits in one of 51 groups. This is one of them.
All 1293questions, and every group →
Or ask the question directly and skip the categories.
Book thirty minutesStill 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.