Discover the two critical decision types—One-Way and Two-Way Doors—that can transform how you tackle decision paralysis in agile teams. Packed with practical tips, coaching questions, and insights into empirical product development, this article from Pawel Rola empowers Product Owners and other Scrum professionals to drive innovation and agility.

In diesem Artikel erklärt PST Simon Flossmann, wie er 3 typische Probleme in hybriden Meetings löst

Digital.ai releases an annual 'State of Agile' report which I am eagerly anticipating. While I wait for the 18th report to be released, I want to take a moment to look at how we have talked about Agile has changed over time.

Many confuse operating models with organization design. Operating models, as defined by Jeanne W. Ross focus on daily operations, resources, governance, planning, performance but are too narrow to shape the whole org-design. Organization design, shown in the Star Model by Jay Galbraith, aligns strategy, structure, processes, rewards, and people. Confusing the two causes local fixes without systemic change — and culture quickly eats strategy when the system stays the same.

Waste hides in “the way we’ve always done it.” In Scrum, Lean thinking is about spotting waste—whether it’s defects, overproduction, bloated backlogs, or wasted talent—and making it smaller, less important, or gone. Here’s how to see it, reduce it, and free your team’s focus.

Mixing SAFe and LeSS inside one product does not work. LeSS is not just a framework but a full organizational design that demands deep structural change. This article explains why SAFe and LeSS conflict and when it is possible to pilot both in the same company.

A modern, agile approach to transforming legacy software, which is often too risky for a complete rewrite is possible. The strategy combines three key elements: the Strangler Fig Pattern, an incremental method of building new services around an old system; AI-powered code generation tools like Blitzy and Claude, which automate the bulk of the coding work; and the Scrum framework, which provides the framework for managing this complex, iterative process. I emphasize that this approach not only mitigates risk but also redefines feedback loops in product development, turning them into a source of creative input and personal growth rather than just criticism.

Pricing is a hypothesis about value, willingness-to-pay, and customer behavior. In this blog, we explore TAP’s pricing formula and show how Scrum Teams can run lightweight experiments, fake doors, A/B tests, and packaging trials, to validate pricing early. Treating pricing like backlog items ensures empiricism guides not only what we build, but also how we sustain value.

Warum agile Praktiker perfekt für das KI-Zeitalter aufgestellt sind.

This blog post introduces a survey about the Agile Product Operating Model (APOM). Dave West explains that Scrum.org is investing in APOM due to challenges organizations face with Product Ownership and the limitations of project-based approaches for managing digital assets. Many organizations, despite calling themselves "product organizations," still operate within a project culture, leading to misaligned and disempowered product teams. APOM aims to provide a unified set of ideas, bringing together Scrum, Nexus, EBM, and modern product thinking to help organizations align, fund, and operate their "products" more effectively. The author emphasizes that APOM is not a prescriptive methodology but a framework of ideas that organizations must adapt to their own context, and encourages participation in the survey to further develop this body of knowledge.

Defining product in Scrum is a fundamental choice. A narrow scope gives focus but risks local optimization. A broad scope brings adaptability and customer-centricity but may blur priorities and vision. The right balance turns Scrum into a true driver of business transformation.

アジャイルマニフェストの最初の一文――「私たちは、ソフトウェア開発の実践、あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている」――は、しばしば見過ごされがちですが、その核心には謙虚さと好奇心があります。「アジャイル開発」は完成したレシピではなく、探求のマインドセットです。今日、多くの組織は「ベストプラクティス」に固執し、フレームワークを固定化してしまいます。しかし、複雑な課題に必要なのは経験主義――仮説を立て、実験し、振り返り、次を決めることです。実際に、スクラムを一時的にやめてみたチームが「スプリントゴールの価値」を再発見した事例や、製薬会社の部門が小規模チーム構造を試し、効果を確認した事例があります。アジャイルは、組織運営においても継続的な実験と改善を求めています。

The first line of the Agile Manifesto—“We are uncovering better ways of developing software by doing it and helping others do it”—captures the humility and curiosity of its authors, yet it is often overlooked. Agile was born as a mindset of exploration, not a recipe of fixed practices. Today, many organizations confuse “good practices” with “best practices,” clinging to frameworks like Scrum, SAFe, or the “Spotify model” instead of running experiments to discover better ways of working. Complex problems such as delivering customer value or organizing teams require empiricism: forming hypotheses, running experiments, reflecting, and deciding what to do next. Two real-world stories illustrate this—one where a team paused Scrum to test Kanban and rediscovered the power of Sprint Goals, and another where a pharmaceutical department experimented with temporary small teams and learned that size and structure matter. Organizations thrive when they embrace curiosity, empiricism, and continuous experimentation.

The belief that working in parallel through silos is efficient is a myth. It doesn’t speed things up; it throws up walls between teams and creates a tangle of dependencies, misaligned priorities, and extra overhead.

In the world of Product Development, there are only two big problems which need to be solved: Are we building the right product? Are we building the product right? There are many approaches that help the developers to build the product in the right way, enabling great quality. However, building the Right Product is often challenging because it is not an issue of capability or technology but more often it is an issue that stems from a lack of understanding or working with assumptions.

In diesem Artikel beschreibt PST Simon Flossmann, wie du in 5 Schritten Scrum Master werden kannst.

Why Knowledgeable Agile Practitioners Are Perfectly Positioned for the AI Era and the Era of ‘Good Enough’ Agile Is Over.

From initial conception through post-launch phases, product managers are responsible for customer research, feature development, and overall product strategy. Think of them as the ultimate jack-of-all-trades in the business world who oversee the entire lifecycle of a product. 

One practice from Kanban that I think is often overlooked is related to the flow of work. Work on the Scrum board should flow from left to right - but it shouldn't flow backwards.

Definir un producto es central a la mentalidad de producto. Hay muchos aspectos a considerar, como la visión de producto, objetivos de producto, métricas, modelos de negocio, entre otros. El siguiente canvas es una idea de cómo enfocar la definición de producto.

The Scrum Guide urges teams to base decisions on what is observed. But what does that look like in real teams, with real complexity? Let’s unpack the word and its impact.

Every product begins with a spark: a frustration, a market gap, or even an accident. But sparks aren’t finished products; they’re hypotheses waiting to be tested. In The Anatomy of a Product, we call this the Spark of Life: the messy, human moment that reveals a problem worth exploring. Scrum gives us the perfect framework to nurture sparks responsibly: observe before you build, frame the problem clearly, and prototype to learn. Not every spark will grow into a product, but every product begins with one.

A Scrum Team thrives when every voice is heard. Facilitators and Scrum Masters play a vital role in making space for quieter team members. With intention and a few well-tested techniques, we can shift the dynamic and bring more perspectives into the conversation. Sometimes the quietest voice in the room has the most important insight. From using silent writing and Liberating Structures to creating psychological safety and embracing silence, these ten approaches empower facilitators to create inclusive environments where all voices are heard. These strategies can help bring forward valuable perspectives that might otherwise go unnoticed, whether you're working with a reflective thinker or someone hesitant to share.

Verwenden Sie keine LLMs mehr für Probleme, die korrekte, reproduzierbare Antworten erfordern; KI liefert weder die erforderliche Genauigkeit noch die Reproduzierbarkeit.

Effective Agile-transformation needs: deep and narrow change, top-down and bottom-up support, and strict volunteer contracts — driving 2x–5x gains in speed and adaptability.

Learn the basics of AI in just 30 minutes with my free crash course "AI Quickstart For Agilists".

In diesem Artikel beschreibt PST Simon Flossmann, wie er seine Workshops mit KI verbessert.

Stop Using LLMs for Problems That Demand Correct Answers.

When I first started working with Scrum Teams, one of the things that struck me most was the Product Owner accountability. The Product Owner is accountable for maximizing the value of the product. It is simple but profound - they are ultimately accountable for the value that the product delivers.

“Aligned Autonomy” is a concept that aims to strike a balance between autonomous decision-making and alignment with organizational goals and values. What does Autonomy mean in a scaled environment with multiple teams? What does Alignment mean? How can we design an organization with aligned autonomy at scale?

Scrum doesn’t suggest—it asserts—that knowledge comes from experience. Not analysis paralysis, not over-planning, not theorizing. Real insight comes from doing. Here’s why that matters more than ever.

Wir haben das alle schon erlebt: Sie bereiten sich auf die nächste Retrospektive vor und bitten ChatGPT um Hilfe: „Ich brauche ein paar Vorschläge für die Retrospektive“, tippen Sie. Was bekommen Sie zurück? Allgemeine Retrospektivenmuster, die Sie schon hundertmal gesehen haben.

The article uses an example to illustrate how tying individual bonuses to the number of high-priority bugs leads to unhealthy behaviors, like manipulating bug priorities and avoiding accountability. The core issue is not software bugs themselves but the management practice that creates perverse incentives and damages collaboration and quality culture. It recommends focusing on collective learning, root cause analysis, and sharing knowledge, instead of linking personal targets to bug counts.

The article introduces the hierarchy of strategic foci — product, operational, and customer. By defining the top-5 organizational capabilities, leaders can identify the primary focus and build an organizational design aligned with strategy.

In diesem Artikel beschreibt PST Simon Flossmann 3 Template, um Sprintziele zu formulieren.

What a shame: We are often ignoring the benefits of Meta Prompting, or having a conversation with the AI, before proceeding to the task.

User stories are one way to describe Product Backlog items, but too often they’re misused or forced into every situation. The original intent, from Extreme Programming, was about sparking collaboration through the 3 Cs: Card, Conversation, Confirmation, not filling in a rigid template. Scrum doesn’t prescribe a single format, and alternatives like Job Stories or Hypothesis-Driven Development can be more effective depending on the context. At the end of the day, the value comes from the conversation, not the wording.

Lean thinking is foundational to Scrum—but too often, teams overload themselves with wasteful rituals and bloated backlogs. This post explores how Scrum encourages clarity, simplicity, and focus on what truly matters.

Ihr LLM-Tool denkt nicht. Es ist ein statistischer KI-Papagei: ausgeklügelt und mithilfe von Millionen von Gesprächen trainiert – aber dennoch ein Papagei. Teams, die mit KI scheitern, verstehen das entweder nicht oder tun so, als ob es keine Rolle spielen würde. Beide Fehler sind kostspielig.

In order to create valuable and useful products, it is necessary for the Product Owner to understand the needs and expectations of the customer. However, it is not always possible to have direct access to the end user. And that could create some challenges. In scenarios, where the Product Owner does not have a direct access to the end customer, they will have to rely on other approaches to build an hypothesis of the needs and expectations of the customer. In this article I explore one such approach - Personas.

If you’ve ever been a Developer on a Scrum Team, you’ve probably experienced this moment: you’ve completed all of the work you originally planned for the Sprint, and there are still a few days left. What now? It might seem like a good idea to just pull more work into the Sprint, but that sometimes causes more harm than good.

The article contrasts traditional and Agile organizations through Galbraith’s Star Model, showing how strategy, structure, processes, rewards, and HR policies shift to enable adaptability in uncertain environments.

In diesem Artikel beschreibt PST Simon Flossmann, die 4 Karrierepfade für Scrum Master.

Your LLM tool doesn’t think. It’s a statistical AI parrot: sophisticated and trained on millions of conversations—but still a parrot. Teams that fail with AI either don’t understand this or act as if it doesn’t matter. Both mistakes are costly.

Scrum is founded on empiricism. But what does that actually mean in practice? In this post, we unpack the true meaning of “empirical” and what it looks like in high-performing Scrum Teams—plus what to watch out for when teams ignore reality.

A few years ago the buzz word in the Software Industry was #Agile, then came #Devops and now certainly the word that is ruling the roost is #AI. In these changing times where the lines are getting blurred and roles are evolving at a rapid pace; how can Product Ownership remain untouched by AI.

El refinamiento es una práctica saludable en Scrum para mejorar la transparencia del Product Backlog y la entrega de valor. Hay muchas prácticas, técnicas y herramientas para llevarlas a cabo, sin embargo, su ejecución debe llevarse a cabo teniendo en consideración algunos aspectos que se muestran a continuación:

If you are thinking about "saving money" by eliminating the Scrum Master, think again! They are the glue that holds the Scrum Team together. What are good communication, effective events and a focus on value worth, after all? A pretty penny, I'd say.

The Scrum Master role is at risk of fading away unless the profession changes. Too many organizations misunderstand the accountability, reducing it to administrative tasks instead of leadership. The Scrum Masters who will thrive are those who grow beyond facilitation, actively protect empiricism, influence at the organizational level, and focus on delivering real outcomes. This article explores the challenges facing Scrum Masters today and the skills they need to remain relevant in the years ahead.

There is an annual "State of Agile" report which has been produced by Digital.ai for the past 17 years. One of the most interesting questions that is asked in this survey is "Why did your company adopt Agile"?. What I find fascinating is that for 14 of the last 17 years, the answer has almost always been something along the lines of "Accelerate Time to Market" or "Accelerate Software Delivery". Last year, for the first time, the answer changed pretty significantly.