by Stefan Wolpers|FeaturedAgile and ScrumAgile Transition
TL; DR: Tokenmaxxing Or Reinventing the Wheel
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.
Your team has a Definition of Done for a product increment. It has none for the 20-plus AI-supported outputs that leave the team each week: status reports, stakeholder emails, release notes, and updates for the C-level. Each one carries your team’s name. “I know quality when I see it” is the standard most teams actually run by, and you cannot audit it, teach it to a new colleague, or defend it when a claim turns out to be wrong. The AI Definition of Done fixes that with one page per task class, agreed by the team, before the output ships.
Your team ships AI outputs that nobody fully trusts; you needed to be quick, and “dirty” tagged along. That ungoverned automation becomes AI debt the moment a stakeholder asks who owns it. The AI Delegation Lifecycle turns six agile skills you already practice into six explicit decisions that govern delegated AI work and produce audit-ready evidence without a separate report.
TL;DR: Compounding Systems and Agents Go Hand-in-Hand
Every AI conversation starts from zero because the model forgets who you are. The Claude Cowork Online Course teaches you to change that: build persistent Skills, connect your tools, and assemble agents for recurring work. No coding.
Thesis: “A prompt disappears after one use; a Skill compounds across every session.”
