Introduction: a new term for an emerging reality
When I started talking about IAgile™ on assignment, the same question kept coming back. Why a new word? We already have AI, we already have agility — what good is one more term?
The answer rests on an observation I would rather situate than present as universal. In the organizations where I work — large structures engaged in an agile transformation at scale — AI and agility are not 2 separate subjects that occasionally cross paths. They meet everywhere at once: in the roles, in how teams are composed, and above all in the way value flows from one end of the chain to the other. Where they meet, something appears that has its own logic and its own conditions for success. That place is what deserves a name.
That name is IAgile™.
2 misunderstandings to clear up straight away. IAgile™ is not an equipment plan — handing licences to an agile organization mostly produces dormant licences. Nor is it an agile veneer laid over a data team. The starting observation is more down to earth: AI makes agility more necessary because it accelerates the market, and agility makes AI usable because it gives it a decision-making frame. Each can be worked on separately — that is in fact what most organizations do, with 2 budgets, 2 sponsors and 2 roadmaps that never talk to each other. Running them together enriches the way value is created, and that is what we at inspearit call Augmented Agility. IAgile™ names the reading and the principles; Augmented Agility, the organizational state they produce.
This article sets out what IAgile™ is: its DNA, its 2 reciprocal needs, its principles, its transformation axes, what it concretely changes in the team and in the roles, and a lived example.
1. The core of the concept: AI and Agility share the same iterative DNA
Look closely at an effective interaction with a generative AI. You formulate an intention — the prompt. The AI produces a result. You assess the gaps, you refine, you run it again. In 30 seconds you have completed a full cycle, and that cycle is one agility has been practising for 20 years.
It has a name, and it is older than agility itself. It is the Shewhart cycle, which Deming popularized to the point that we now call it the Deming wheel, the PDCA. Plan, Do, Check, Act, which SAFe renders as Plan, Do, Check, Adjust. The only difference with your conversation a moment ago is duration. Where agility thinks in 2-week sprints, your iteration lasts 30 seconds.
AI did not invent a new way of working. It compressed to the extreme the one agility had already identified as the most effective against complexity and uncertainty.
Mature agile teams take up AI faster than the rest, quite simply because they already had the reflexes. Conversely, teams that think in waterfall transpose that logic onto the tool and reproduce the same traps: a specification document for the prompt, validation committees, and the big-bang delivery of a disappointing result.
IAgile™ operates at 2 levels that must be held together. At the micro level, AI creates ultra-short iterative cycles. That speed is only worth something when channelled by agile reflexes: structured feedback, quality criteria, continuous improvement. At the macro level, it accelerates the entire market. Product cycles compress, competitors that integrate it build a lead that is hard to close, and absorbing that acceleration requires organizational agility — the ability to pivot, to deliver continuously, to adapt. Holding one without the other does not get you far.
2. Why AI needs Agility
Generative AI is a tool for dialogue, not a conventional piece of software. You do not hand it a specification; you entrust it with an intention and you steer it. And all steering is iterative — you correct as you drive.
Without an agile frame, 2 traps recur with striking regularity in the teams I support. The first is the one-shot. A single, carefully prepared prompt meant to solve everything, followed by disappointment and then abandonment of the tool.
The second is the infinite loop — endless iterations that burn hours without converging. These are the first 2 anti-patterns the IAgile™ principles neutralize.
Both traps have the same origin: the absence of agile reflexes. Research confirms it at greater scale. The DORA 2025 report (State of AI-assisted Software Development, Google Cloud) observes that AI improves the throughput of development teams, but often at the cost of stability when the foundations are missing (quality practices, feedback loops, small batches). The researchers draw an unambiguous conclusion: AI is an amplifier. It amplifies the strengths of disciplined organizations just as it amplifies the weaknesses of the others.
AI brings speed, agility brings direction. Without a frame, speed produces nothing but noise — faster.
3. Why Agility needs AI
Agility was designed in a world where the bottleneck was the teams' production capacity. Two-week sprints, quarterly PI Plannings, monthly releases — that whole rhythm was calibrated on the speed at which a human produces.
AI changes that equation, and the data is starting to quantify it. In the controlled experiment by Peng et al. (2023), developers assisted by GitHub Copilot completed a single, well-scoped implementation task 55.8% faster than the control group. The figure measures that task, not a team's productivity. McKinsey, for its part, observes common tasks completed up to 2 times faster, with a caveat that matters: on genuinely complex tasks, the gain falls below 10%. AI massively accelerates the repetitive and barely touches the difficult.
And then there is METR. The randomized controlled trial published in 2025 takes experienced open-source developers, working on their own codebases, and measures 19% more time spent with AI tools. The participants themselves were convinced they had been faster. I have no elegant way of making that result sit alongside the previous 2, and I am wary of articles that find one. The 3 studies measure different situations, which explains part of the gap but not the fact that experts were wrong about their own speed. What can be said honestly is therefore more modest than what one usually reads. AI does not add a fixed acceleration; it amplifies the system it enters. Standard task and explicit context: the gains are massive. Complex codebase whose context lives in the expert's head: friction wins. Which of those 2 situations most resembles your team is the open question, and I have no simple test to offer you for settling it.
There is finally an argument deeper than speed. AI collapses the entry cost of the very methods agility has recommended for 20 years without always managing to get them practised. Lean canvas, story mapping, BDD, OKRs: these practices were not failing because they were bad, but because preparing, formalizing and maintaining them cost more time than teams had. It is the famous square-wheels cartoon, where everyone is too busy pushing the cart to fit the round wheels waiting inside it. With AI, a first story mapping is drafted in 1 hour instead of 2 days, BDD (Behaviour Driven Development) scenarios are generated from acceptance criteria, OKRs are broken down and reworded in session. Above all, artefacts stop being photographs that expire: a backlog, a dependency map or a canvas maintained by an agent becomes living again. And what AI makes affordable here is not the specification of the solution — it is the objects that make it possible to judge it. Agility no longer needs AI merely to keep up with the market's pace; it needs it to finally deliver on its own promises.
The strategic consequence lies elsewhere. The bottleneck moves: from production to decision, from execution to prioritization, from delivery to strategic alignment. This is what we have been observing in the field for several years, and it is striking to see established frameworks arrive at it from their own side. Launching AI-Native SAFe® in June 2026, Andrew Sales, Chief Methodologist at Scaled Agile, put it this way: “The bottleneck has shifted. The challenge for organizations is no longer whether they can build something, but validating that what they are building is safe, secure and valuable.”
A word here on how this article summons SAFe, since it has just done so and will again. Scaled Agile is not a source of truth for us but a thinking partner — an actor observing the same terrain with its own angle and its own interests, whose formulations deserve to be discussed rather than recited. When our readings converge, the observation gains solidity, without either one authorizing the other. And when they diverge, we will say so.
The sprint is not going away. It accelerates, and the organization has to learn to decide at the pace at which it now produces. The opposite shortcut is much in the air at the moment, so let us be direct. AI does not weaken agility and takes none of its advantages away. It makes glaring what agility was already saying and what we were hearing badly: being agile is emphatically not settled in production alone. As long as producing was the bottleneck, the 2 could be confused, and looking agile was possible by simply being quick to deliver. That shortcut no longer holds, and it is probably the most uncomfortable consequence of all this for organizations that had built their reputation for agility on their sole capacity to ship often.
4. The 5 principles of IAgile™
Once the convergence is understood, the practices remain. Rather than a list of good practices, IAgile™ is formulated the way agility itself was formulated: through preferences. As in the Manifesto, the right-hand column remains useful and no one is asking you to throw away your specs. Several of those right-hand values are in fact prerequisites, and an organization that abandoned them believing it was gaining agility would be misreading the whole thing. Each preference also neutralizes a specific anti-pattern, one I have seen at work more than once. They are therefore written from what fails in organizations, which makes them less elegant than a manifesto but more useful when you are looking for a way into the subject.
1. Structured intention over frozen specification
Preparing is not specifying, and the whole nuance sits there. Generative AI demands a very precise idea of what you expect from it: an explicit intention, a target result, criteria that will say when it is good. That framing cannot be improvised. What does not work is the other object — the specification document, that closed and exhaustive description of the solution written before the first attempt, for a tool designed to converse. AI therefore moves the value of preparation in 2 opposite directions: it raises the value of framing and collapses the value of specification. You no longer prepare the solution, you prepare what will allow you to judge it. Set your intention and your stopping criteria, launch, observe, reformulate. 30 seconds per cycle. It is the Manifesto's “responding to change over following a plan” applied to the half-minute — and the Manifesto never said not to plan.
Anti-pattern neutralized: the one-shot. The carefully prepared 2,000-word prompt, the disappointing result, and the team concluding that “AI doesn't really work”. It is not the preparation effort that failed. It is having described a solution instead of an intention, and having bet everything on a single pass.
2. Judgement over validation
Validating is stamping at the end of the chain. Judging is deciding at every turn whether what comes out deserves to go further. The human in the loop is therefore not a quality controller placed after the fact; they are the AI's Product Owner, and their work starts at the first result, not the last. The previous principle gave them something to judge with — an intention and criteria; this one says that no one else can use it in their place. AI produces without value judgement. It does not know whether its result is good, relevant or dangerous, and it does not know any better that it is time to stop. That discernment cannot be delegated, and it is what turns a series of iterations into convergence. Formal validation obviously keeps its place. The problem is not that it exists; it is that it is often the only moment when anyone looks at the result.
Anti-pattern neutralized: the infinite loop. Criteria set and then never held up against the result: the team polishes, polishes again, and no one calls a stop. The final deliverable is longer and less clear than the manual version.
3. Context over prompt
A team that has spent 6 months on a product knows things the best prompt in the world does not contain. Performance is settled there, not in the phrasing. A prompt wears out in one conversation; a context compounds, exactly as a team compounds its Definition of Done or its architecture. This discipline has a name, Context Engineering, which we at inspearit break into 2 parts. The Data Context covers your data, your decisions, your history — structured and queryable for what can be, carried by people for what cannot. The Method Context covers your conventions, your templates, your working rules, encoded so that AI applies them. It is a team's IAgile™ asset, and probably the only one that does not copy across from one organization to another.
Anti-pattern neutralized: generic AI. Brilliant, unusable answers, because the tool knows nothing about your product, your constraints, or what has already been decided.
4. Augmentation over automation
An IAgile™ team is a team where every member uses AI as a copilot — the Scrum Master to analyse blocking patterns, the PO to prepare prioritization, the developer to accelerate code — and where the team stays at the centre. Automation replaces, augmentation multiplies, and the difference is not merely a moral one. Ignoring this principle now has a measured cost. Harvard Business Review, in May 2026, documents the “psychological debt” of AI: 6 negative effects recorded across 1,200 employees, from excessive cognitive delegation to identity threat — a debt that eats into adoption and return on investment. Which means, very concretely, that a sustainable pace is costed in the same place as everything else. A team that avoids the tool after 6 months has consumed its licences and its support for nothing, and that argument passes in a steering committee where a plea about well-being does not.
Anti-pattern neutralized: the exhausted team. People who produce more but understand less, who doubt their own competence and end up avoiding the tool.
5. The frame that enables over the control that forbids
At scale, the question is no longer “how do we prompt well” but “how do 300 or 3,000 people use AI without chaos or paralysis”. The IAgile™ answer is a pragmatic frame that makes usage legitimate, tooled and safe, rather than a restrictive policy that everyone works around. Scaled Agile took a step in that direction with AI-Native SAFe® in June 2026: governance and ethics raised to the foreground, smaller teams augmented by AI, an explicit design of the handoffs between humans and AI, and an AI Value Architect role tasked with steering value, costs and risks across trains and portfolios.
Anti-pattern neutralized: Shadow AI. Teams switching to unmanaged personal tools because the official frame is too slow, too closed, or non-existent.
5 preferences, 5 anti-patterns. It is also a diagnostic grid. Spot the dominant anti-pattern in your organization — one-shot, infinite loop, generic AI, exhausted team or Shadow AI — and you will know which principle to work on first. To get out of gut feel, we at inspearit use a 4-level IAgile™ maturity grid that situates a team on each of these principles. It serves to structure a conversation. It predicts nothing, and I would be hard pressed to demonstrate that a team moving up a level delivers better.
5. From the value stream to the 3 axes of transformation
The principles structure a team's practice. An organization's transformation starts elsewhere: with its flow.
Producing fast is not producing value
One question precedes the axes and decides whether they succeed. Are we accelerating a step, or the chain? With AI, producing fast has become easy. Producing value has not become easy at all. A developer who codes twice as fast shortens nothing if their delivery waits 3 weeks in review, if the decision to prioritize it took 2 months, or if no one checked that the feature met a real need. An AI plugged into an isolated link moves the bottleneck one notch along and piles up upstream a stock the rest of the flow cannot absorb. Lean and the theory of constraints established this decades ago, and AI has not repealed it. Optimizing a link does not make the flow win.
This observation has a translation in steering: the shift from a logic of outputs to a logic of outcomes. Scaled Agile has made it one of the pillars of its AI-Native version, taking up Mik Kersten's formula that, in the age of AI, the foundations of output-centred management collapse. We share the observation and we add what makes it operative. Counting deliverables was never a good measure of value, but as long as producing was expensive, volume produced remained an acceptable proxy for the effort expended. AI breaks that proxy. When generating costs almost nothing, the number of features shipped no longer measures anything at all, and an organization that keeps relying on it accelerates without knowing towards what.
There is a question no one ever asks in a workshop. What, in this chain, must stay slow? The spontaneous answer is “nothing”, and it is wrong. Arbitrating a priority, refusing a plausible but unsuitable solution, understanding why a user works around the feature you have just delivered — these are not residual slownesses we will eventually automate away. They are the only places in the flow where someone checks that we are building the right thing. Removing them in the name of speed amounts to taking quality control out of a production line because it lengthens the lead time. An IAgile™ transformation therefore does not seek to take the human out of the flow; it seeks to give them time back where their judgement decides, by massively unloading them where it decides nothing.
This is what the augmented VSM (augmented Value Stream Mapping) exists to settle, and it is our answer to the question every reader is asking at this point: “where do I put AI in my organization?”. Not a catalogue of use cases — a tool. You map the real value stream of a team or a train, as lean teaches, then you qualify each step. Where is time lost? Where can AI augment — that is, accelerate while keeping the human as judge? Where must it abstain: judgement, arbitration, relationship? AI then installs itself where the flow calls for it, not where the demo was impressive.
With the flow mapped, the transformation unfolds along 3 axes. All 3 must be held simultaneously, otherwise one undermines the other 2.
Augmented humans and team performance
The first axis is the one where you think you have finished when you are only starting. Deploying a tool costs nothing; getting it into the working gesture costs everything. The dumbest rule is also the most reliable: if a developer has to open a tab to go and fetch the assistant, they will not go. The one that gets used is already in the IDE, in the ticket, in the channel where the team talks. The rest of the axis is role-by-role support work, and that is where the psychological debt measured by Harvard Business Review is prevented. It is also where the managerial shift plays out, from controlling tasks to orchestrating augmented teams — a shift usefully tooled by the AI-Native Compass and Management 3.0.
Discovery, steering and organization augmented by data
The second axis is the least spectacular and the most profitable. AI does not only serve delivery: it serves knowing what you are building and why. Synthesizing 4,000 customer verbatims instead of reading 40 changes product discovery. Mapping dependencies before a PI Planning rather than during it changes the conversation you have there. What I look at first is not the deliverables produced but the decision loops — the delay between the moment information arrives and the moment someone settles the matter. It is the direct consequence of the bottleneck having moved.
AI governance, risk and sovereignty
The third axis comes down to 3 objects, and none of them is a 200-page document. A body that decides — preferably one that already exists rather than one more committee. A map of usage kept up to date, because a list of tools ages in 6 weeks. And a written position on sensitive data, published before someone pastes a contract extract into a consumer chatbot. The AI Act and the GDPR set the floor; your sector's requirements set the rest, and they are often the expensive part.
This sovereignty requirement has a methodological corollary: IAgile™ is deliberately tool-agnostic. The 5 principles, Context Engineering and the augmented VSM deploy just as well on market copilots as on an entirely internal second stack — a model hosted by the IT department, outside the Microsoft or US ecosystems if the context demands it. The reflex objection “external AI is banned here” therefore does not close the door on transformation; it specifies its architecture.
6. What IAgile™ concretely changes in the team and the roles
A presentation of IAgile™ stays abstract if you do not say what it changes for people. 2 questions arise, and the second makes little sense without the first. What is the team made of, and what becomes of each of the roles it houses?
The team before the roles
Before looking at what each role becomes, a more uncomfortable question. Does the agile team itself keep its shape? Our answer is no, and the AI-Native Team model proposed by SAFe offers a useful way of putting it. It drops job titles and describes the team by the capabilities it brings together. There are 4. Product carries the vision and the customer anchoring. Builder produces the system with the help of AI. The Domain Expert brings the business context that makes it possible to adapt the solution. And AI itself is counted as the 4th capability, not as a tool the team uses. The announced format is 3 to 7 augmented people.
The shift runs deeper than a redrawing of job descriptions. A team is no longer defined by what it contains but by what it brings together: a business view, a product view, a capacity to build. SAFe proposes to describe how it works in 3 beats — Align, Sense, Respond — that is, align on the intention, continuously pick up signals from the product and its users, adjust. It is our PDCA redistributed, since Scaled Agile places AI's contribution on the Do and Check phases and returns Plan and Adjust to the human. The split is illuminating and we take it up, with one nuance that matters. AI is not absent from Plan. It weighs on it through what it makes easy, and an intention formulated in front of a tool that produces instantly is not the one you write in front of a blank page. Principle 2 becomes more demanding as a result, not less. Judging is not only arbitrating results; it is watching what the tool does to the question you ask it.
The most interesting of these 4 capabilities is the Domain Expert, and that is where the IAgile™ reading adds something. The agility of the last 20 years had progressively absorbed the business into the Product Owner — a single point of contact, a proxy, often a bottleneck. AI-Native SAFe® reintroduces it as a capability in its own right. Why now? Because AI does not know what it does not know. Deprived of a human carrier of business context, it produces generic plausibility — exactly the anti-pattern that principle 3 neutralizes. The Domain Expert is the Data Context made flesh. Part of it can be written down, and it should be, but the part that matters most stays in someone's head and is recruited rather than documented.
One reservation deserves stating, and it is exactly the use we make of this model. These 4 capabilities are the ones that produce. None covers facilitation, psychological safety or collective maturity. In a team of 3 to 7 people iterating continuously with a tool that produces faster than they decide, that is a blind spot, and psychological debt does not prevent itself. We therefore take from it a minimum composition rather than a complete inventory.
Role by role
These capabilities say what the team must bring together, not who carries it. Existing roles therefore do not disappear; they become its carriers. And for most of them, AI does not redefine the role — it gives back the means to exercise it. The official definitions of the PO, the Scrum Master or the RTE never mentioned writing tickets or preparing steering committees; it is the capacity to do, cannibalized by operational work, that had brought them back to it. It is the square-wheels argument applied this time to people. Of the 5 roles that follow, 2 nonetheless escape that logic.
The Product Owner becomes a curator of value again. That was already the definition; it was no longer quite the daily reality. They no longer write user stories by hand — AI drafts them from the product backlog — and the time freed goes back where it was expected all along: challenging prioritization, arbitrating between stakeholders, reading the political context, staying in contact with users.
The Scrum Master recovers the role of learning facilitator. Ask an experienced Scrum Master what takes up most of their week and they will rarely talk about psychological safety and often about boards to keep up to date. AI analyses the patterns of past sprints, spots recurring blockages, prepares retrospectives. What comes back to them is markedly harder: getting a senior developer to say in front of the others that they did not understand the story. No tool will do that, and no board replaces it.
The RTE (Release Train Engineer) and the SAFe coach become architects of feedback loops again. At scale, AI detects dependencies, simulates impacts, accelerates PI Planning preparation — all that coordination work that was absorbing most of their calendar. What does not automate is the room. Aligning 8 teams around a vision is done with people looking at each other, not with a dependency board, however accurate.
The developer, for their part, gains a role that did not exist: orchestrator of augmented code. Copilot, Cursor, Claude Code — the tools are there and everyone has them. What sets IAgile™ developers apart is not their usage but their capacity to challenge the output: critical review of suggestions, refusal of plausible but unsuitable solutions, maintenance of an architectural coherence AI does not perceive on its own. This is not about recovering a craft but about learning a new part of one.
The manager is the second exception, and the harshest. Part of what has legitimized the role for 30 years — synthesis, control and validation — AI now does better and faster. What remains is telling someone you have decided against their view, and staying in the room afterwards. No synthesis does that. But writing that the value of management “shifts” is a little glib when it is your own job.
New roles are appearing too. The AI Value Architect is the most formalized example to date: guarantor of the value AI produces as much as of its costs, its ethics and its risks.
IAgile™ removes none of the existing roles and rewrites almost none of them; it gives them back the means to express the value they already carried. What it changes is the way they combine: fewer juxtaposed job titles, more capabilities brought together around a single result.
7. In the field: a lived example
The mission second brain I am going to talk about has existed since August 2025. For the first few months I fed it by hand. Since February 2026, most of it has been automated: meetings, committees, workshops and coaching sessions are transcribed, an agent produces the summary, extracts the decisions and the actions, and files everything in a structured mission context. The actions feed a real-time kanban. The filing rules are written in routing files the agent reads before classifying, and in case of ambiguity they push it to propose 2 options and ask rather than decide alone. The whole thing stays hosted inside the client's internal ecosystem. These are the words of identifiable people turned into text; they do not leave their premises.
What broke was me. In automating, I authorized systematic recording: everything was captured, so everything came in. But I work on several subjects in parallel, and the context began to saturate. The larger the base grew, the less sharp the summaries were, because the agent had to sort between materials that had nothing to do with one another. I had to go back, purge, and then decide upstream what I would not record. Many meetings are of no interest whatsoever to a knowledge base, and pouring them in gives them the same weight as an arbitration committee.
That is the most useful correction I have drawn from the exercise, and it qualifies principle 3 as I formulated it above. A Data Context is not measured in volume. Between a large quantity of data and a smaller but well-adjusted one, the second feeds the model markedly better. The gesture that counts is therefore not capturing everything, it is choosing what you do not capture. And that technical decision settles a good part of the human question along the way, since the surest way not to keep someone's words is not to record them.
3 of the 5 principles can be read openly in this cycle. The routing files and the structured context are the Method Context and the Data Context of principle 3. The intention set and then adjusted by usage, with an MVP of structure rather than an exhaustive filing plan, is principle 1. And “the agent proposes, the human arbitrates”, with every summary reread in 2 minutes, is principle 2 in its most everyday form. What the setup still does not know how to do is decide on its own what deserves to enter the base: that is still me, meeting by meeting. What it has delivered is more modest than what I was hoping for in February. Action tracking no longer gets lost between 2 committees, and weak signals — a subject that comes back 3 times without moving — become visible because the corpus is queryable.
Nothing spectacular in the plumbing. An agent, a few rule files, a systematic reread, and 6 months to understand that the problem was not the quality of the agent but the quality of what I was giving it to read. Building a knowledge base is nothing extraordinary, and if the exercise had stopped there I would not be recounting it.
What is surprising comes afterwards, when you stop feeding the base and start questioning it. Instructing an audit. Confronting a declared maturity score with what the corpus actually says. Producing a handover deliverable. Mapping stakeholders, cross-referencing their interactions and seeing who influences what appear — something no org chart shows. Work like that is now built in a few hours, when it used to take months of cross-checking. And the limit is no longer the machine. It was first the quality of what I gave it to read. It is today what I have the idea of asking it.
And this is only one person on one assignment. What occupies me now is the notch above: the same reflex pooled at the scale of a team, then of a value stream, then of an entire organization. A queryable mission corpus makes visible what is blocking a mission; several linked corpora would make visible what is blocking a train, then a portfolio, and would make it possible to treat problems where they repeat rather than where they make the most noise. I am not there, and I know no one who is. Yet that is the side on which what comes next will be settled, rather than in the next model.
Conclusion: not one more framework, an approach
IAgile™ is not a new framework that would add itself to Scrum, SAFe, Kanban or the others. Those frames remain relevant and will stay so. Scaled Agile is itself betting that they evolve, with AI-Native SAFe®, and we share that bet for our own reasons. IAgile™ is an approach that augments them — a way of integrating AI into those frames to make them more effective in a market that AI has itself accelerated.
4 things to take away, and the first is that IAgile™ is a convergence, not a juxtaposition. Stacking AI on top of agile without looking at the value chain end to end amounts to accelerating one link while the others hold the flow back, and to confusing production speed with value creation. Real convergence goes deeper than tooling the roles: it changes how teams are composed and where the organization decides.
IAgile™ then shares the same DNA as agility — iteration, feedback, inspection and adaptation. That makes it natural for mature agile organizations, and gives the others one more reason to invest in their fundamentals. It does not reinvent the wheel; it accelerates what agility had already identified as the right answer to complexity. Research points the same way: AI amplifies disciplined organizations and destabilizes the rest.
The third point lies in the 5 preferences, each of which neutralizes an observed failure rather than an ideal. The most structuring is context over prompt. What your team has codified of its data, its decisions and its conventions is the only asset that does not copy across from one organization to another. The tools are the same for everyone.
The last point is that IAgile™ deploys along 3 simultaneous axes: the performance of augmented teams, steering by data, pragmatic governance. Holding a single axis creates an imbalance that ends up blocking the transformation.
Those who adopt this reading stop seeing AI and agility as 2 separate programmes. They see a single transformation, Augmented Agility, better accompanied consciously than endured.
That leaves the practical question. Where do you start? Not with a programme — with 2 gestures. First identify your dominant anti-pattern among the 5 (the maturity grid is for that) and work on the principle that neutralizes it. It is a team job, not a company-wide project. Then launch an augmented VSM on a volunteer team: half a day is enough to map the flow and decide, data in hand, where AI will create value in your organization. If you are hesitating over the team, take the one that complains the most — it already knows where things jam.
References
- Peng, S., Kalliamvakou, E., Cihon, P., Demirer, M., The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590, 2023: task completed 55.8% faster with Copilot (controlled experiment).
- McKinsey Digital, Unleashing developer productivity with generative AI, 2023: common tasks up to 2× faster; gains < 10% on highly complex tasks.
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 2025: randomized controlled trial, 16 experienced open-source developers, 246 real tasks; 19% more time spent with AI tools, while participants believed themselves faster.
- Google Cloud / DORA, State of AI-assisted Software Development (DORA 2025 report): AI improves throughput, often at the expense of stability; amplification effect on organizational strengths and weaknesses.
- Scaled Agile, Inc., AI-Native SAFe®, 23 June 2026: integrated AI governance, augmented teams, AI Value Architect role; quote from Andrew Sales, Chief Methodologist.
- Scaled Agile, Inc., AI-Native Teams, Achieving AI-Empowered Agility and Outcome-Driven Product Development in AI-Native SAFe (SAFe framework, 2026): teams of 3 to 7 people structured by 4 capabilities (Product, Builder, Domain Expert, AI), Align / Sense / Respond operating model, PDCA split between AI (Do, Check) and human (Plan, Adjust), shift from output-based to outcome-based steering, with Mik Kersten's formula on the collapse of output-centred management.
- Harvard Business Review, The Psychological Costs of Adopting AI, May 2026: “psychological debt”, 6 negative effects measured across 1,200 employees.
- inspearit, IAgile™: AI Transformation: the firm's offering and the concept of Augmented Agility, including Context Engineering (Data Context / Method Context), the augmented VSM and the IAgile™ maturity grid; Structuring large-scale setups; Management 3.0 training.