by Stefan Wolpers|FeaturedAgile and ScrumAgile Transition
TL;DR: Polished Artifacts, Unchanged Decisions, Or Ten Backlog Anti-Patterns AI Makes Worse
Add AI to a Product Backlog process that already struggles, and everything seems to improve within an afternoon. The problem is that polishing artifacts with AI doesn’t fix the root cause: the basis for the team’s decisions doesn’t change; AI only removes the visible discomfort that used to signal something was broken, along with some of the pressure to fix it. AI applied to a dysfunctional system – here, the Product Backlog process – makes the dysfunction look like progress.
This is the first article of a new series that explains the uselessness of bolting AI onto a dysfunctional system. It explains why generative AI worsens ten Product Backlog anti-patterns, how polished AI artifacts can hide missing evidence and authority, and how teams can check whether their process is fit for AI.
Thesis: Adding AI onto a dysfunctional system, for example, the Product Backlog, makes ten typical backlog anti-patterns worse, because polished AI artifacts hide missing customer evidence, decision authority, and feedback; the article explains these mechanisms, their costs, and how teams test whether their process is ready for AI.
TL;DR: The AI Workflow Inventory Finalizes the A3 Delegation System
You probably know your own AI shortcuts: the colleague who drafts the stakeholder update, the nightly job somebody set up before they left, the interview notes that go through a model on demand. However, I want to challenge you: that perceived knowledge can create false confidence, because it feels like knowing the team’s way of working with AI, when it is still only a diffuse understanding of the practice. Ask the team to combine those individual accounts into one list, and you may discover how little of the whole anyone can see. The AI Workflow Inventory is the artifact for that list: one row per recurring task, refined into provisional task classes to prepare the team’s next AI delegation decisions.
This is another post from the series on building the A3 Delegation System in public. (I gladly answer all questions you have, and yes, I am considering creating an A3 Delegation application.)
Thesis: The AI Workflow Inventory is a one-page canvas listing every recurring task a team already runs with AI, grouped into provisional task classes. It is A3 Delegation System’s seventh artifact. This article explains how to build it in one 60-minute session.
TL;DR: AI Transformations and Agile Transformations Rhyme
AI adoption seems to be scaling: 37% of respondents in McKinsey’s 2026 survey report an EBIT effect from AI, and Gartner finds that 22% of organizations have scaled it across business units. Now, Agile practitioners have seen this combination before, as AI transformations and Agile transformations rhyme. There are five classic failure patterns from the Agile transformation adventures that are back under new names: from mandates from above to licenses mistaken for training to greenfield showcases to parachuted consultants to promised payroll savings dressed up as strategy. They share one condition: organizations make AI decisions at organizational scale without leaving inspectable evidence at the workflow level in the trenches. And for good measure, let us throw in ignoring culture and excluding most of the organization’s people in the process.
The A3 Delegation System is not an AI-transformation method. It is a deliberately low-tech, paper-level discipline that lets a team produce that evidence in hours, and this article spends as much time on where the system stops as on what it does. If you are a Scrum Master, Product Owner or Manager, an Agile Coach, or a Project Manager who has to argue upward about AI, the last section gives you one thing to do this week.
Your organization counts AI tokens, seats, and pilots, but can anyone name a single decision those numbers actually changed? Tokenmaxxing is only the symptom; five old Agile Laws explain the cause, and each one comes with a test you can run this week. There is no need to reinvent the wheel with AI transformations and learn the hard way what the veterans of other transformations already figured out.
Thesis: Tokenmaxxing is the vanity metric of pushing low-value work through an AI tool solely to inflate usage metrics. Tokenmaxxing emerged in 2026, when large technology companies began ranking employees by token consumption on internal leaderboards. The behavior is rational for the individual but useless for the organization because tokens measure input rather than outcomes. The five Agile Laws in this article explain why organizations keep making this mistake and what to measure instead.
by Stefan Wolpers|FeaturedAgile TransitionLean and Product
TL; DR: The “Agile to the Product Operating Model” Survey Results
Between August 2 and August 10, 2026, 48 practitioners participated in my Agile to Product Operating Model (POM) survey, which tries to shed light on what is actually changing.
Let me summarize the answers for you: the reported transformations change decision-making less than the Cagan framework suggests. Where respondents report improvements, they appear in delivery and collaboration rather than in business results. Unfortunately, the human side of the transition is the least encouraging part of the answers.
Take all the following information with a grain of salt, given that the sample size is so small. (I recall the good times when 1,000 to 2,000 people would participate in a Scrum master salary report, but those times seem to be over, despite my asking 39,000 people for their contributions via a newsletter.)
Thesis: Product operating model transformations mostly change vocabulary and organizational structure while leaving the decision system, who decides what gets built, on what evidence, at what speed, largely untouched. AI is changing product decisions independently of POM transformations.
The debate over the product operating model (POM) has a data problem. Most of us, including me, argue from the organizations we know.
When I interviewed Marty Cagan, see the article below, he called a Scrum team “quite amateur compared to a professional product team.” I later called the theater version of the shift from Scrum/Agile to POM product washing, a form of “transformation by reprinting business cards.” Consultants generalize from their clients and bloggers from their respondents.
I have not seen a dataset showing what changed across several hundred organizations after they moved beyond Scrum as they had practiced it. That is what this survey is for. And it takes only three minutes.
Organizations are moving away from “good enough Agile,” while AI reduces the cost of producing software. That change seems uneven, as engineering is hardly free, but a team today can, indeed, build the wrong thing faster and with fewer people, provided a valid credit card is available.
Making product decisions, or having product sense, therefore, matters more than ever.
A POM is supposed to move those decisions closer to customers and give teams problems to solve rather than feature lists to deliver. “Product washing” produces different results: roles are renamed, Scrum events disappear, and approval power stays with the same stakeholders as before.
We have strong opinions about which version is more common. Too bad, we have little comparable data. This is why I ask you to invest 3 minutes of your time and join the “From Agile to the Product Operating Model: What Is Actually Changing?” survey.
The survey asks, for example:
Who is pushing the move toward a product operating model, and what role does AI play?
What changed in delivery speed, customer value, business results, and team morale since switching to a product operating model?
What happened to Scrum or agile events: abandoned, repurposed, or relabeled?
Who decides what gets built today: leaders assigning features or teams investigating problems?
When nobody knows whether an idea is worth building, what settles the question: debate, research, a disposable prototype, or simply shipping it, now that agentic coding has become affordable?
Who Should Answer the “From Agile to the Product Operating Model: What Is Actually Changing?” Survey
I encourage you to take part in the “From Agile to the Product Operating Model: What Is Actually Changing?” survey if you work in or around product development as a product owner, product manager, Scrum master/agile coach, project manager, developer, designer, (product) leader, or consultant.
Your organization does not need to be adopting a product operating model. The survey includes a short route for organizations that are not making that move, and I want those responses, too. (The product operating model already has enough cheerleaders.)
I am particularly interested in organizations that tried a product operating model and later abandoned or reversed the change. Failed experiments rarely appear in conference talks, but they may tell us more than another transformation success story.
What Happens to Your Answers
The survey is anonymous and requires no registration. I will publish the results openly on this blog; the resulting report will be free to everyone.
Learn more about AI Builders with our AI and Scrum training classes, workshops, and events. You can secure your seat directly by following the corresponding link in the table below:
You can book your seat for the training directly by following the corresponding links to the ticket shop. If your organization’s procurement process requires a different purchasing approach, please contact Berlin Product People GmbH directly.
✋ Do Not Miss Out and Learn More about the Product Operating Model — Join the 20,000-plus Strong ‘Hands-on Agile’ Slack Community
I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
