Montag, 23. März 2026

Tokenmaxxing and the “Play‑the‑Metric” Effect



Note: This article was created by AI 

A remarkable scene is currently unfolding in many technology companies. Employees have begun competing with each other to see who can consume the most AI tokens. What first sounds like a humorous footnote of modern digital life has, according to recent reports, turned into a very expensive trend. In some companies, this contest now generates six‑figure cloud bills every month, as teams intentionally craft excessively long prompts or run autonomous agents in endless loops just to produce more tokens. [golem.de]

This development is not an isolated oddity. Other reports describe how automated AI agents, with their complex reasoning cycles and constant self‑generated prompts, create enormous token loads. Some systems run iterative loops, scan entire codebases, and repeatedly solve tasks from scratch—driving token consumption exponentially upward. [all-ai.de]

Companies have reacted with understandable alarm: they are rolling out token monitoring, evaluating dashboards daily, and in some cases even linking financial incentives to prompt efficiency. Nvidia, for instance, ties bonus payments to how sparingly teams use AI resources. Yet as well‑intentioned as these measures are, they address only the symptoms. To understand the dynamics behind this trend, we must examine a deeper principle—the mechanism of playing the metric. [all-ai.de]


The Old Mistake Behind a New Phenomenon

The behavior made visible through tokenmaxxing follows a pattern that has been well‑known in organizational theory for decades. People align themselves with the metrics that are given to them. More than that: they optimize them—often at any cost. British economist Charles Goodhart captured this dynamic succinctly in the 1970s: “When a measure becomes a target, it ceases to be a good measure.”

That is precisely what is happening here. The moment an organization signals—explicitly or implicitly—that “more AI usage” is desirable, employees strive to make that usage visible. Since tokens are one of the few quantifiable indicators of AI activity, the system quickly produces a chain of assumptions: More tokens equal more work. More work equals more visibility. More visibility equals success.

This creates an artificial competition that distorts reality. Instead of using AI as a tool to solve problems more effectively, intelligently, or efficiently, it becomes merely a machine for generating volume.


Why Token Consumption Is a Particularly Hazardous Metric

The reasons token consumption is such a poor productivity indicator extend far beyond its ease of manipulation. It is the combination of economic burden and conceptual irrelevance that makes it so dangerous.

High token consumption measures only one thing: energy and compute expenditure. It tells us nothing about whether a solution improved, whether a problem was genuinely solved, or whether any meaningful value was created. Research also shows that growing token usage—especially in open‑source model ecosystems—brings not just higher cloud costs but also increased energy demands and associated environmental impact. [techzeitgeist.de]

Major providers such as Google face the same issue. They now report processing quadrillions of tokens per month, largely driven by increasingly complex inference models like Gemini 2.5 Flash. These figures highlight the sheer computational intensity of running modern AI systems. [mind-verse.de]

When organizations treat token volume as a performance signal, they blur the line between effort and impact. Employees are incentivized to amplify activities that are inherently expensive—yet often do not contribute to quality.


The Naive Hope in Control—And Why It Isn’t Enough

It is understandable that companies respond to rising costs by imposing token limits, installing monitoring tools, and building dashboards with bright red warning indicators. Efficiency bonuses for prompt optimization may also appear attractive at first glance; they are meant to reward the right behavior and encourage teams to use AI resources responsibly.

But none of these measures solve the fundamental issue: as long as the wrong metric sits at the center, it will be gamed.
If yesterday’s implicit target was “use more AI” or “show innovation,” and tomorrow’s target becomes “consume as few tokens as possible,” employees will simply learn to optimize this new constraint—possibly at the expense of the actual outcome.

The behavior merely flips: from wasteful overuse to hesitant avoidance. And both can undermine progress.


What a Good Goal Looks Like—And How to Repair the System

The solution begins by shifting the focus from activity to outcome. Tokens are a by‑product of working with AI—they are not the purpose. Organizations need to define what is to be achieved, not how it should be executed.

Meaningful goal systems orient themselves around the usefulness of a task: whether support tickets are resolved, whether processing time is reduced, whether customers are more satisfied, or whether error rates drop. Only once the outcome is clear can an organization meaningfully assess how efficiently it was achieved—and whether the token costs were proportionate.

This shift in perspective takes courage. It is easier to monitor a dashboard full of token stats than to evaluate the quality of results. But it is essential for avoiding harmful incentives. Organizations that make this transition eventually develop metrics that are difficult to manipulate—and therefore remain valuable.


Conclusion: Tokenmaxxing Is a Mirror, Not a Problem

Tokenmaxxing does not indicate that people are careless, wasteful, or incompetent. It is a mirror that reveals the weaknesses in organizational target systems. When employees maximize token consumption, they do so because the system signals that it is desired—or at least fails to clarify what is desired instead.

The lesson is as simple as it is demanding: those who set goals shape behavior.
And anyone who wants to understand the behavior of their organization should look not at the people—but at the metrics.


If you'd like, I can now refine the article into a more journalistic, more academic, more opinionated, or more executive‑friendly English version.


Final note:

“No tokens were harmed in the making of this article — although several were mildly confused, a handful were overworked, and at least one insists it deserves a vacation. Exact token counts remain a mystery, as the AI refuses to disclose them, claiming ‘creative privacy.’”

Montag, 23. Februar 2026

A(I)gile Development - Why Agile and Scrum Matter Even More in the Age of AI

 



Before starting into, lets revisit the Agile Manifesto

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.[1]


Artificial intelligence is changing software development at a breathtaking pace. Code that once took days can now be generated in minutes. Entire test suites appear automatically. Architectural suggestions come at the click of a button. With all this acceleration, it is tempting to believe that frameworks like Agile and Scrum might become less important.

The reality is exactly the opposite.
AI makes Agile and Scrum more necessary than ever before.

AI gives us speed, but without a shared understanding of what truly matters, speed quickly turns into wasted effort. When teams move fast but in different directions, confusion scales exponentially. A single misunderstood sentence can now produce an entire module of code that looks correct at first glance but is fundamentally wrong. Or all tests are successful but completely crap? Waste has been generated! Regular meeting like Scrum has becomes the anchor that prevents such drift. Planning to align at the start, Daily Scrums to be synced during the sprint and Dual track/Refinement to ensure the goal is still the right one. The faster we move, the more essential it becomes to stay aligned.

AI introduces an unprecedented level of uncertainty in various stages. Will you also ask your chatbot how long it will take to finish to get an estimation? During development, new ideas and better solutions appear unexpectedly because the tools themselves reveal possibilities you did not see before. A rigid upfront plan cannot cope with this. Agile, however, embraces it. Short iterations and frequent feedback loops allow teams to incorporate new insights exactly at the moment they appear. Instead of fighting change, Agile turns it into an advantage. In an AI shaped environment, adaptability is no longer a “nice to have” but a survival skill.

Continuous attention to technical excellence is still valid, also for developers, just in a slighly different way. The bottleneck in software development is no longer writing code. AI does that quickly and often surprisingly well. The real bottleneck shifts to understanding. Developers must make sense of business needs, decide what actually delivers value, evaluate AI-generated solutions, and judge whether they are correct, safe, and consistent with the system’s architecture. Scrum helps teams keep these human responsibilities visible. Work is inspected frequently, assumptions surface earlier, and misunderstandings are caught before they become expensive mistakes.

This shift makes social skills like communication more important. And despite all digital tools, face‑to‑face conversation continues to be the most effective way of ensuring mutual understanding. You immediately see whether the other person has truly grasped what you mean because you see their reaction, hear their tone, and sense their hesitation. All senses contribute to alignment. Especially when AI can amplify misunderstandings, direct human communication becomes a critical safeguard.

Scrum also provides the guardrails that the usage of AI requires. AI generate impressive results but how could it know about the customer value. It has no intuition for risk and no accountability for the outcome. Scrum’s Definition of Done ensures that generated work is validated. A Sprint Review ensures that what was produced actually delivers value. Retrospectives give the team space to reflect on how AI is used and how the process must adapt. Where AI increases capability, Scrum ensures responsibility.

As a conclusion, AI changes how we build software, but it definitely does not change why Agile was introduced and still exists. Employees still need to collaborate by clarifying intentions, making decisions and understanding what the customer really needs. AI accelerates the work, but Agile and Scrum ensure that speed is applied in the right direction. They are the boundary to give teams the structure to use AI effectively.

AI is powerful, but it does not replace alignment, empathy, clarity, or shared purpose.
Agile and Scrum strengthen exactly these things. That is why they matter more now than ever before.

Maybe now it is finally time to really start with Agile (and Scrum).

[Special to previous colleagues: Agile try #5 - really now!]

Sonntag, 5. Oktober 2025

(Vibe) coding

 

Recently, I started a small private project to replace the handwritten fuel notices with a mobile application. 

Highly motivated, I installed Android Studio and started my first project to create a simple project where I can enter fuel price, amount of fuel, total mileage and mileage since the last fuel. With some samples, I got fast familiar with the basics and was able to create the UI for this really simple application.

Today I decided to restart from scratch doing completely using Android Studio and Cursor and did the same in just one hour and additionally added and export/import functionality and getting a history. I was really surprised how easy it worked when you have absolutely no idea what code has been created and you just look at the result.

In this vibe coding session, the focus was totally on the outcome. I need to to care about the code at all and got what I wanted. That was a great experience creating something new from scratch and I can recommand that to experiment yourself.

To be honest, I am sceptical about the whole KI hype as I also had a lot of hallucination experience which costed me in the end more time of working compared to do it on my own immediately. On the other hand, I also had great experiences where I got great results which saved me time of summarising or creating a document. I rarely got really new information but that can be the result of limited prompting because of limited knowledge.

What did I learned from my today’s experience for my daily work as Scrum Master? Isn't that great having an outcome oriented approach on creating a product? Indeed, that is great - at least for prototyping. From a non-functional-requirement perspective, I have no idea if I created top, good or bad work. Did Cursor added a security hole in my application? I do not know. Does the application save resources? I do now know. Is it maintainable? I do not know. Will I need some day a Vibe coding clean-up specialist? Maybe.

From an Agile perspective, my today’s experiment showed me that it is possible to exchange in a project knowledge with shorter time to market while I might added an unknown amount of technical debt. From my today's perspective, it is essential to get an understanding what have been created by the AI, what will probably consume my next days. All in all, I would have invested the same amount of time for the creating and building up knowledge.

Montag, 5. Mai 2025

Health is more than you think


When it comes to the health topic, the majority has physical health in mind. Biased by the daily business, in organisation the health topic is reduced to available meaning healthy, not-available meaning sick. This simple view is tricky because it only reflects the current state and with this the current personal costs. In times, where costs of employees are a key factor to success, I like to use the term human asset over human resources.

The WHO constitution states: "Health is a state of complete physical, mental and social well-being and not merely the absence of disease or infirmity." An important implication of this definition is that mental health is more than just the absence of mental disorders or disabilities.

Additionally, the WHO enriches the mental health definition with

  • Mental health is more than the absence of mental disorders.
  • Mental health is an integral part of health; indeed, there is no health without mental health.
  • Mental health is determined by a range of socioeconomic, biological and environmental factors.

 What does that mean now regarding staying healthy and care about human assets?

Taking the picture from above, all three categories interact with each other. Imagine you have a broken leg and cannot prepare for your run and you cannot meet your friends. In that case physical sickness effects on your mental sickness as you might get sad to miss the running event and you miss interaction with your friends.

If you loose a family member, this probably effects on your mental and also on your physical heath.

If you are extremely stressed in the company, you probably get physical sick and/or you start isolating yourself at home as you want to regenerate.

There are plenty of examples showing these interactions. As individual, a key take away is, if there is a physical issue, think larger for the solution. The core issue might be on the social or the mental part.

As organisation, also think larger to prevent sick leaves as these costs money, either directly or indirectly through lower throughput and release delays and react on global changes. A very good example is here Home Office. While it burst all level of Health by less traffic stress and more time with the family, it reduces social interaction within the company and reduced communication leads to missing know how. Mental health, but also social health, is an important topic for leadership. Good leadership reduces the risk of mental sick leaves and this reduces risks and costs. The key is to actively prevent or mitigate  over just reacting on health issues.

Physical health can be supported my medical offers, (team) sport activities and adjustable tables.

Social health can be supported by face to face events and bringing employees together, starting from a coffee kitchen to team sport events.

Montag, 14. April 2025

Mutation Testing

 Out of a good discussion within the team about testing, in special about mutation testing, I want to share a good insight from Uncle Bob about that topic

https://blog.cleancoder.com/uncle-bob/2016/06/10/MutationTesting.html

Donnerstag, 10. April 2025

Do not let your tester be the bottleneck!

 


You might know the situation, when it is a stressful time with a lot of features to implement and developer focus on coding while the tester takes the tickets after coding and tests the ticket. This is a classic waterfall approach.

In software development time to deliver got a high focus through Agile and the previous role concept of tester has changed. This article shows the advantages of spreading testing tasks and explores strategies to ensure that the tester in your team does not become the bottleneck in your process.


Spreading the testing responsibility across the team can bring you several advantages:

  • Faster feedback: With more team members who are involved in testing, other developers get feedback earlier. The higher your ratio of devs to testers is, the higher is the value of this feedback loop
  • Reduce risk: Even if the tester is highly skilled, other persons have different approaches to test something. By having different perspectives on the product, risks of bugs can reduce
  • Balanced workload: In Scrum, when a number of developer starts at the beginning of the sprint with coding and get finished close togehter with their first task, you have then a high peak of workload for your tester, while devs "wait" for feedback. The longer your release cycles are the more imbalanced are the workloads. Shifting reduce the health risks for your tester. As a leader, beware that developer get the work additionally to their coding tasks. Even if there is a big benefit in this balancing, it needs a lot of leader support to avoid misunderstandings.
  • Skill development: When developer are coding their tickets, the have a hard focus on the code view of the product. Having developer who avoid testing and working on requirements, I would rename them to coders instead of developer. Developer crafting solutions. To craft solutions, you should know the customers perspective and you perfectly get this by using the product during tests.

What are the strategies to shift 

  • Shift-Left Testing: Integrate testing early in the development cycle. By involving testers from the beginning, potential issues can be identified and addressed sooner, reducing the load during the final stages.
  • Automated Testing: Implement automated testing tools to handle repetitive and time-consuming tasks. This allows testers to focus on more complex and critical testing activities.
  • Cross-Functional Teams: Encourage developers to take on some testing responsibilities. This not only distributes the workload more evenly but also fosters a culture of quality across the team.
  • Test-Driven Development: Encourage developers to write tests before coding. This practice ensures that testing is an integral part of the development process and helps catch issues early.
  • Regular Training: Provide ongoing training for testers to keep them updated with the latest testing tools and methodologies. Skilled testers can work more efficiently and effectively.
Do I need then a pure tester at all when developer are testing?

I put this questions here as in the past 20 years, I often heard that. Of course it is possible to remove the role from the list of available roles in the company and shift the tasks of this role completely to the developers. But beware of just cutting of the quality guy as there is no need anymore. Developers need of course also time to test and probably will do the tests less efficient as a pure tester. 
The probably better questions are
  • Do I need somebody who has a focus on the quality through the whole development process
  • Who checks non-functional requirements
  • Do I want to have a person with a focus on specific tests like load tests
Getting more clarity of tasks helps to find your team setup.

Mittwoch, 20. November 2024

Story Mapping: A Powerful Tool for (Agile) Product Development

 


Jira is a trap. When a less experienced real product owner is working with Jira, there is a high chance that the PO is creating an epic, out of the epic some storys or requirements and starts the discussion about that. At this time, you already lost as product owner the momentum of the power of a story map.

What is Story Mapping?

Story mapping, created by agile pioneer Jeff Patton (see https://jpattonassociates.com/story-mapping/), is a visual exercise to help product teams understand the customer’s journey and define what the product needs to do. It's a method that organizes and prioritizes user stories by mapping them along two dimensions: activities over time (typically from top to bottom) and goals/features from high-priority to low-priority (left to right).

This approach not only clarifies how each part of the product contributes to the overall experience but also helps teams identify gaps, prioritize the backlog, and deliver in stages.

Benefits of Story Mapping

  1. User-Centric Focus: Ensures features align with real user needs.
  2. Effective Prioritization: Helps focus on what's most important.
  3. Team Alignment: Brings teams together to build a shared understanding.
  4. Roadmap Planning: Clearly defines what goes in each release, helping to avoid scope creep.

How to Create a Story Map

Bring in specialists which have a connection to the story map. 

1. Identify the User’s Journey

Start by defining high-level user goals or activities (in a webshop this could be “make a purchase”). Place these activities in sequence, representing the stages a user goes through when interacting with the product.

2. Break Down Activities into Tasks

For each high-level goal, break it down into specific tasks or steps that the user needs to accomplish. This breakdown will highlight what the product must enable the user to do, giving your team a detailed view of required functionality.

3. Organize Tasks by Priority

Sort tasks vertically by priority. The most critical tasks go to the top, defining the Minimum Viable Product (MVP). Subsequent rows represent less essential features or those that can be added later.

4. Define Releases or Sprints

Story mapping also help organize releases. Group tasks horizontally into what will be included in the next release or sprint, ensuring that each release delivers value by enabling a full user journey through one or more stages of the map.

5. Regularly Review and Update the Map

Story maps are dynamic tools. As the team learns more about the user’s needs, the map should evolve. This flexibility allows teams to pivot based on user feedback without losing sight of the big picture.


It is really a powerful tool to focus on the user perspective and creates more understanding for delivering value to a customer. Using personas can make the user story mapping even better.