Thank you, Paddy! By integration debt, I mean the technical debt associated with integration that we accumulate as a result of pushing away the effort of integrating your products developed in silos. I don’t know if anyone has classified it that way officially or not. However, you could see it as a subset of technical debt. Before I started on the engagement to construct the operating model the program was already using elements of SAFe, but you can never lift and shift any framework; that would be like — “I don’t know the question, but I sure know the answer”, which does not make sense. You almost always have to customize a framework to your context, and that’s what I was brought in to do. The operating model I put together did include several structural elements of SAFe. This article is specific to one important part of the operating model — business agility at the point of arrival ; there needs to be focus on how to iterate on outcomes when defining the value being requested. More often than not, this is a cultural problem due to the way organizations manage their funding — project and portfolio based funding as opposed persistent funding of product teams — which forces business teams to sneak in as much as possible in their project requests as opposed breaking value down into iterate-able smaller pieces of work. If organizations start adopting persistent funding, the only thing that would remain variable in the trinity is SCOPE, while COST and TIME will be fixed! Then the business teams would be more incentivized to break the scope down, because each of the features will get into the queue and would be addressed based on business value scoring and prioritization; allowing changes to the priorities in a more rapid manner. Business teams should be allowed to change their minds on what they perceive as “value”, for them and for the external customers!