Insights

The real question isn't Scrum versus the V-Model — it's how both worlds work together inside one programme, instead of teams working against each other.

In regulated technical environments (for example under quality models such as ASPICE), development teams increasingly work in an agile way, while approvals, supplier contracts and milestones still need to be steered through a phase-based model. In these programmes, I build a shared governance layer that synchronises both delivery models instead of pitting them against each other.

• A shared milestone calendar that both sprints and phase gates feed into.
• Requirements and change traceability that shows the same status in both worlds (for example via a linked DOORS/Jira set-up).
• Clear interface roles between the Product Owner (agile) and the programme/change board (phase-based).
• Early-warning indicators rather than status colours: trend before state.
• Escalation paths that bind both sides equally.

Do your teams work in sprints while releases run on phase gates? Where exactly that breaks is usually quick to name — an intro call, or the project health check first.

The first 90 days decide whether a programme becomes governable again — or whether trust and deadlines keep eroding.

As an interim manager, I typically take over programmes where transparency, delivery reliability or stakeholder trust has broken down. A structured 90-day roadmap restores control quickly, without overloading the team further.

• Days 1–15 – Diagnosis: a stocktake of scope, resources, open risks and the actual status (not the reported one).
• Days 16–45 – Governance build-up: establish a schedule, clear accountabilities (RACI), a reporting cadence and escalation paths from scratch.
• Days 46–75 – Stabilisation: deliver visible quick wins, actively manage the critical path, synchronise suppliers and interfaces.
• Days 76–90 – Proof: deliver credible milestones and rebuild trust with the customer/management through facts, not announcements.
• Throughout: a single source of truth for status – no conflicting reports to different stakeholders.

At the start of a roadmap like this? The project health check gives you a first read in two minutes, and an intro call covers the rest.

Leading a programme across several time zones, cultures and supplier tiers is first a governance question — collaboration comes second.

In international programmes with teams spread across Europe, Asia and the US, a good schedule alone is not enough. What matters is a structure that brings together different working hours, communication styles and escalation cultures without slowing any single team down.

• A binding, cross-time-zone rhythm for status, decisions and escalations (rather than purely ad-hoc communication).
• Clear interface roles between the internal team, Tier-2/Tier-3 suppliers and the customer organisation.
• Actively accounting for cultural differences in feedback and escalation behaviour, rather than ignoring them.
• Supplier negotiation as an integral part of programme management, not a separate silo.
• One shared language for status and risk, regardless of who is reporting from where.

If your programme is drifting apart across sites and time zones, an intro call is enough for me to place where governance has to take hold first.

You do not pass an assessment with documents. You pass it with a development organisation that genuinely works the way the documents claim.

The V-model is often misread as the opposite of agile. What it actually describes first of all is a symmetry: every specification level on the descending branch has a corresponding verification level on the ascending one. Customer requirement and system test, system architecture and integration test, software detailed design and unit test. Whoever elaborates the left-hand side has thereby committed to the right.

That coupling is exactly where things break in practice – and almost never for lack of will. It breaks for lack of connection between tools and responsibilities. Requirements live in one system, architecture in a second, test cases in a third, and changes travel by email. Each level on its own is maintained perfectly well. It is just that nobody can answer which test covers which requirement in under two days.

An assessor does not ask whether a document exists. He asks whether one work product follows consistently from the previous one, and whether the organisation can show that without a week of preparation. That, at heart, is the difference between Level 1 and Level 2: Level 1 means the work gets done. Level 2 means it is managed – planned, monitored, with defined work products under configuration control.

• Bidirectional traceability that holds in both directions: from customer requirement through to test case and back again – not as a spreadsheet reconstructed afterwards, but as a by-product of the daily work.
• A change process that moves requirement, architecture, test and schedule together. A change that only reaches the requirements tool is not a change; it is an inconsistency with a delay built in.
• Work products under configuration control, with a defined maturity. „Version 0.9, for the past eight months“ is a process finding, not an interim state.
• Roles that are actually staffed. A process that assumes a configuration manager who does not exist describes a different organisation from the one in the room.
• Metrics somebody reads. Figures collected only for the assessment are the first thing an assessment notices.

Assessment coming up, or one that went badly? An intro call is enough for an honest read on how far the road actually is.

A bug in an app costs you an update. A bug in a vehicle rollout costs you a recall – and during an update a car is not a phone. It belongs to somebody, and it has to work tomorrow morning.

Over-the-air updates are often treated as a solved problem: the technology works, the rest is logistics. In reality OTA shifts the load from development into release. As long as software was flashed at the end of the production line, start of production was the boundary. With OTA every delivery changes a fleet that is already with customers – across several countries, with different type-approval states, different hardware states, and a way back that is expensive or absent.

UN R155 and R156 turn this into a regulatory obligation: a cyber security management system and a software update management system, both demonstrable, both auditable. Which in practice means the question ‚who decided, when, and on what basis, that this build goes to two million vehicles?‘ has to be answerable at any moment – answerable, not reconstructable.

The governance for that is unspectacular, and effective precisely because of it. At its core it is a handful of agreements kept consistently, rather than an extensive process framework that gets bypassed when it matters.

• Pre-integration cycles that find defects before a release date depends on them. Integration is a rhythm, not a phase at the end.
• Change-freeze windows ahead of critical delivery gates – binding, with a defined and documented exception route instead of a culture of quiet exceptions.
• Vulnerability and patch management on production systems, running separately from the feature release. A security patch must not wait for the next feature drop.
• Regional requirements early rather than late: operating, certification and data requirements differ substantially by market, and they belong in the schedule rather than trailing it.
• A fallback that has been rehearsed. A rollback nobody has ever exercised is an assumption, not a plan.
• Evidence as a by-product: who decided, on what data, accepting what residual risk – captured at the moment of the decision, not weeks later for the audit.

If your update process is heading into release or currently stuck: book an intro call — no obligation.

A status report tells you what somebody was willing to write down. What people actually believe, you learn somewhere else – and usually in passing.

When an external arrives in a programme that is in trouble, the team has no particular reason to tell him the uncomfortable truth. Quite the opposite: an interim manager is often read as the bearer of bad news, sometimes as the advance party for consequences. In that position you get exactly the information that is already in the report – and it is rarely the information you need.

The sentences that matter are not spoken in the status meeting. They are spoken at the coffee machine, in the corridor, in the five minutes before a meeting starts: ‚we have actually known since March that the date will not hold.‘ ‚That interface has never worked, we just never measured it.‘ Sentences like that are not gossip; they are the working basis. Without them you plan against a position nobody in the room believes.

So informal access to the team is not a pleasant side effect for me, it is part of the method. It does not come from friendliness alone. It comes from dealing with uncomfortable facts factually and visibly, early on, instead of carrying them upwards. Once somebody has seen that an honest answer brings no trouble, they speak up sooner the next time – and that gain in time is the whole point.

There is a second thing that decides whether you get access at all. An external is eyed at first as the new consultant who turns up with slides and unrealistic ideas. Engineers, though, open up to someone who understands what they are talking about. My route through electrician, state-certified technician and several years as a development and test engineer helps here more than any methodology training: I can push and follow up without the demand missing technical reality – and I can tell the difference between ‚that is not possible‘ and ‚we would rather not‘. Both occur, and each needs a different answer.

On distributed programmes this channel does not appear by itself, but it can be built. In Teams it works if you set it up deliberately: be there five minutes before the meeting starts, leave the call open after the formal part, hold short one-to-ones with no agenda. It is no substitute for the corridor, but it comes close enough – and across time zones it is often the only option there is.

• Listen more than you direct in the first days. Change the process immediately and you will not hear anything after that.
• One-to-ones with no agenda and no minutes – deliberately short, deliberately unstructured.
• Be early on the call and stay after the formal part. For distributed teams, the start and the end of a meeting are the coffee corner.
• A channel that is not the status channel. Where status gets reported, thinking does not happen.
• What arrives informally does not become a basis for decisions until it has been verified – and it is never used against the person who said it. That is precisely what decides whether the channel stays open.
• Keep confidence, upwards too. The value of this access lies in it not becoming a reporting line.

Starting a difficult mandate yourself, or looking for someone to take one on? Let us talk it through — book a call.

Interface chaos between hardware, firmware and cloud is not an automotive phenomenon. The pattern repeats in industrial automation, smart energy and anywhere devices sit in the field — and the blueprint against it is the same.

When a programme tips over at the hardware/software boundary, it is rarely for want of technical skill. It is because nobody has defined, bindingly, which software state belongs to which hardware state, who may release a change, and how a field failure finds its way back into engineering. A task force closes that gap — not through more reporting, but through less room for interpretation.

• Week one: a binding version and configuration matrix — which software state is released for which hardware state, and who decided that.
• One single source of defects instead of three parallel lists held by engineering, manufacturing and service.
• A daily 15-minute cross-discipline sync with fixed participants that replaces status reports rather than adding to them.
• Field returns recorded with a cause assignment rather than a symptom description — otherwise engineering optimises in the wrong place.
• A defined end: the criteria under which the task force is dissolved and responsibility handed back to the line organisation.

Want a first read yourself? The project health check takes two minutes. For the supplier side there is the assessment grid as an Excel template. And if you recognise these symptoms, an intro call is enough for me to place your situation — no obligation.

A backlog with a five-figure ticket count is not a quality problem, it is a prioritisation problem. The question is not how to work through all of it — but what you consciously decide not to work through.

On an infotainment programme at Harman/Daimler I brought a backlog of more than 10,000 tickets down by 85 % without moving the start of production. The lever was not additional developer capacity but a different sorting logic: not by reporting date or by the seniority of the reporter, but by what the end customer actually experiences.

• ABC classification by customer-perceivable impact — not by the internal severity rating, which usually comes from whoever raised the ticket.
• Rigorous merging of duplicates: one real defect, one ticket, however many times it was reported.
• A daily integration routine, so fixes do not sit in branches for weeks and create new defects when merged.
• Plan explicitly around offshore bottlenecks: use the time difference as a rhythm rather than accepting it as an excuse.
• A documented decision not to fix something is a result — it simply has to be taken deliberately and defended towards the customer.

If your backlog is heading in this direction, an intro call is enough for a first assessment.

Both roles lead a programme. The difference lies in whether the conditions for leading are still in place at all — and who restores them.

A conventional project manager drives a programme along a plan the organisation believes in. That very foundation is missing in crisis programmes: the plan exists, but nobody considers it realistic. An interim manager first restores governability — a status you can rely on, clear decision rights, an escalation path that works — and leads after that.

• Interim makes sense when the reporting is no longer believed and dates slip without an identifiable cause.
• Interim makes sense when decisions stall between departments because nobody is formally accountable.
• Interim makes sense when the role has to voice uncomfortable facts without weighing internal career interests.
• Conventional project management is enough when plan and reality broadly match and only capacity is missing.
• Typical mistake: trying to solve it internally for too long — the later the decision, the more expensive the stabilisation.

Unsure which role your situation calls for? That is usually quick to place in a short call.