What the work looks like in practice

A scaled programme kept hitting the same wall at the end of every increment. The teams planned in good faith and committed to their own backlogs. They then collided once the separate pieces met at integration. A signal that one team had assumed was stable would turn out to have changed. An interface that two teams believed they shared meant something different on each side. The retrospectives kept calling this a communication problem and prescribed yet more meetings, yet those extra meetings made very little difference. The deeper cause sat inside the planning process itself. Nothing in that process forced the boundaries between teams to be written down and agreed before the work began.

I borrowed a discipline from an area where it already worked reliably. In AUTOSAR development, software components agree on an interface contract first and then build against it, a habit that keeps their interactions predictable. I took the same idea one level higher and applied it to whole teams. Each team treated the slice of work it owned as an exported interface. They named what other teams depended on and versioned those things. They also stated clearly which parts were guaranteed and which parts were still in flux. Dependency mapping then moved from a side conversation into the centre of planning. The contract between teams became the unit that crossed every team boundary.

An engineer had recently stepped into a coordination role at the train level. The framework describes that role in a single paragraph. Real working life describes it across a whole year. They held the certification and knew every ceremony in the cadence by heart. The harder part was reading the signals that nobody ever writes down. One example is the moment when a small dependency is about to grow into a serious problem. Another is the way a carefully worded status update is really a request for support. They could sense how much authority the role carried against how much the title appeared to promise. They followed the published playbook closely and still felt they were administering a schedule when they wanted to be leading a programme.

We met on a regular schedule, and the agenda was always whatever happened to be live that week. That might be a real decision they were facing or a conversation that had gone sideways. It might also be a risk they could sense without yet being able to name it. They already understood the framework thoroughly, so we spent our time on the texture of the job. We practised surfacing a dependency so that it sounds like shared problem solving. We practised escalating so that people come along with you willingly. We worked out when to absorb a problem yourself and when handing it back is the responsible choice. Over several months the goal shifted from performing the role correctly toward exercising genuine judgement.

An engineering organisation was halfway through adopting scaled Agile. It was treating the whole effort as a process rollout. That meant training the people, installing the ceremonies, running the cadence, and expecting the benefits to follow. On paper the adoption looked comfortably on schedule. In practice you could feel the friction in every session. The framework was being applied word for word to a safety-critical context it was never written to handle. Safety cases, multi-year platform commitments, and a large supplier ecosystem will not bend to a cadence designed for web-scale software. The leadership team had begun to suspect that the method itself was failing them. In reality they had skipped an important step along the way.

I ran a working session for the leadership group around a single question. Where did this framework need rewriting for the constraints they lived with? The session took the form of a structured walk through their real constraints. I illustrated it with concrete examples from leading the same kind of programme at first hand. We separated the parts of SAFe that transfer cleanly into their world from the parts that tend to break under safety-critical load. We then named what it would cost the organisation to leave each weak point unaddressed. The aim throughout was to hand the framework back to the leaders. They left with full permission to adapt it for their own conditions.