Change is inevitable in any organization, from shifting markets to evolving customer expectations. Agile frameworks can help navigate these challenges, but they must evolve alongside the organization. While generative frameworks adapt and grow, rigid ones impose fixed solutions that may become obsolete over time. The key is ensuring your framework supports, rather than hinders, your organization's progress.

Komplexität im Code ist ein oft unterschätztes Problem, das die Leistungsfähigkeit eines Teams erheblich beeinträchtigen kann. Sie schleicht sich heimlich ein, führt zu unübersichtlichem und schwer wartbarem Code und hindert Teams daran, schnell und effektiv auf Veränderungen zu reagieren. Langfristig entsteht daraus ein „Big Ball of Mud“, der Innovationen bremst und Entwickler frustriert. Doch wie können Teams dieser schleichenden Gefahr begegnen? In meinem Blog-Post zeige ich, wie Teams ein Gespür für aufkommende Komplexität entwickeln können und welche Strategien helfen, die Codebasis kontinuierlich zu verbessern. Von der Vereinfachung von Strukturen über die Bedeutung klarer Namensgebung bis hin zur Anwendung der „Pfadfinder-Regel“ – erfahre, warum die Reduzierung von Komplexität eine zentrale Aufgabe für das gesamte Scrum-Team ist und wie sie langfristig den Business Value schützt.

The core strength of Scrum is its ability to take advantage of self-managing teams who are capable of making faster decisions, taking ownership and creating value by helping the customers to respond to ever changing needs of their domain, market. The challenge however is, how many self-managing teams have we encountered in the software world. At least, in the places where I have worked in the past, the sighting was rare to none. It is like going on a birding trip to find a specific bird species only to know that the species has already migrated to some other place. It was here yesterday but now it is gone. The question this situation raises is, if self-management is so important for Scrum or Agility to thrive then why do we have so few self managing teams. And can by simply declaring a team, a self-managing team will make it so magically?

In diesem Artikel erklärt PST Simon Flossmann die 3 Kernkompetenzen Agiler Produktentwicklung

Product Metrics That Speak Wall Street: Turn Misunderstood Products into Investor Gold

Dans ce post, Vivien C. vous parle de son expérience en F1. Faire partie d'une équipe "high performance" - 🏎️ une vraie 🏎️ - et son vécu de membre d'équipe Scrum dans sa version la plus fluide.

Accountability and responsibility are often confused, but the key difference is that responsibility can be delegated, while accountability cannot. This blog explores the distinction with real-life examples, including tax filing and Scrum leadership.

In some of my classes, people tell me they are using Scrum—but they can't call it Scrum. Why? Because someone in their organization had a bad experience with it.

In diesem Artikel teilt PST Simon Flossmann, 7 Tipps, wie du die Sprint-Retrospektiven moderierst. 

An Increment that isn’t inspectable creates blind spots—decisions are based on assumptions, not evidence. In this post, we explore what makes an Increment truly inspectable, common anti-patterns, and how to ensure your Scrum Team delivers transparency every Sprint.

Kontinuierliche Verbesserung klingt in der Theorie großartig: Teams optimieren ihre Prozesse, steigern die Qualität ihrer Arbeit und entwickeln sich stetig weiter. Aber die Praxis zeigt: Es ist oft eine echte Herausforderung, diese Verbesserungen dauerhaft im Arbeitsalltag zu verankern. Warum? 1️⃣ Veränderung kostet Überwindung: Viele scheuen den Schritt aus der Komfortzone, selbst wenn klar ist, dass Optimierungen langfristig Vorteile bringen. 2️⃣ Zeitdruck und Alltagsstress: Die Dringlichkeit, Deadlines einzuhalten, lässt oft keinen Raum für Reflexion und Prozessverbesserung. 3️⃣ Fehlender sichtbarer Erfolg: Verbesserungen entfalten ihre Wirkung oft erst über die Zeit, was kurzfristig die Motivation drücken kann.

If you are managing a product, you need to be clear about what drives value and what doesn’t. Not all bug fixes and refactors are worth it.

In diesem Artikel warnt PST Simon Flossmann dich vor 3 Fehler, die sich in Sprint-Plannings einschleichen

Psychologische Sicherheit ist keine nebensächliche „Nettigkeit“ – sie ist die Grundlage für agile Teams, die innovativ sind, sich an Veränderungen anpassen und Ergebnisse liefern.

The only reason for a Product Owner to exist is to maximize the value of the Product. One of the ways a Product Owner can accomplish this is by ensuring that most valuable items remain at the top of the Product Backlog and the Product Goal underscores their importance. So, how does the Product Owner order the Product Backlog; what techniques can be used? Is MoSCoW a valuable approach? Let’s explore.

Many Scrum Masters see their role as protecting the Scrum Team. But when protection becomes isolation, something is wrong. Shielding a team too much from stakeholders isn't helpful - it hinders collaboration, stifles feedback and erodes trust.

Psychological safety isn’t about fluffy “niceness”—it is the foundation of agile teams that innovate, adapt, and deliver.

Das Sprint Review – eines der zentralsten und spannendsten Events in einem agilen Team, oder? Naja, theoretisch. In der Praxis empfinden viele es als langweilig, ineffektiv oder reine Pflichtveranstaltung. Viele Scrum-Teams stolpern über typische Fallen und verpassen die Chance, echtes Engagement zu schaffen. Das muss nicht sein! Ein gut durchgeführtes Sprint Review kann inspirieren, Energie freisetzen, richtig Spaß machen und eine Plattform für wichtiges, produktbezogenes Feedback bieten. Hier sind 6+ Ideen, wie du dein Sprint Review wieder zu einem echten Highlight machst, das alle begeistert.

In diesem Artikel erklärt PST Simon Flossmann seine 5 Lieblings-Retrospektiven.

Some teams struggle. They flounder in chaos, miss deadlines, and suffer from constant firefighting. Eventually, the pain becomes unbearable, and they take action—hiring an agile coach, changing their approach, or even replacing key team members. Other teams just get by. They hit their deadlines (some of the time). They hold their agile events. They deliver work that’s… fine. Not great. Not terrible. And because the discomfort never reaches breaking point, nothing changes. This is the Region Beta Paradox at play.

Scrum Masters as change agents, often face challenges in becoming effective in their accountability. The reasons behind this can vary, but changes are inherently difficult. People resist change, consciously or unconsciously, and change agents face these challenges on personal, team and organisational levels. On the other hand, the role of the Scrum Master as a change agent is crucial and can profoundly impact the Scrum Team and Organisation. This article describes six characteristics that can guide your growth as a change agent. It is a valuable resource for Agile leaders (Scrum Masters, Delivery Managers, Agile Coaches) who aim to embrace their role as agents of change.

Your organization works exactly as it was designed to work. The results you get—good or bad—are not by chance. They come from the way your teams are set up, the people you hire, the decisions you make, and the processes you follow. It might or might not be what you intended, but it is what your design produces.

In vielen Teams wird der Fokus daraufgelegt, dass jedes Mitglied „beschäftigt“ ist und seine Aufgaben möglichst unabhängig erledigt. Doch ist das wirklich der beste Weg zu großartigen Ergebnissen? Alternativen wie Swarming, Pair-Programming und Mob-Programming werden oft als ineffizient abgetan, doch diese Methoden haben es in sich! Warum? Bessere Lösungen durch kollektive Intelligenz: Gemeinsam erarbeitete Lösungen sind oft durchdachter und robuster. Kontinuierlicher Arbeitsfluss: Keine unnötigen Wartezeiten oder Kontextwechsel – Aufgaben werden schneller und qualitativ hochwertiger abgeschlossen. Stärkerer Team-Spirit: Gemeinsame Verantwortung, bessere Kommunikation und ein echtes Gemeinschaftsgefühl führen zu höherer Motivation und besseren Ergebnissen. Es lohnt sich, traditionelle Denkweisen zu hinterfragen und die Kraft echter Zusammenarbeit zu nutzen!

In diesem Artikel beschreibt PST Simon Flossmann, wie Scrum Master mit Facilitation gängige Problem lösen.

The only purpose of doing Scrum is to create a DONE Increment. To get to a DONE Increment, quality is key. In Scrum Teams Definition of Done enables transparency around quality and releasability of the Increment. However, more often than not the Definition of Done stops at meeting acceptance criteria and completing a few levels of testing. But is that enough to make the product increment releasable; of highest possible quality? Maybe or maybe not.

To stay competitive and relevant as an Agile Practitioner, continuous learning and upskilling in AI are no longer optional but essential for the new world of careers. Take a free AI quiz to see where you stand now.

Every great product starts with a simple idea: solving a problem in a way that matters to people and businesses alike. But what exactly defines a product—and what doesn’t?

Los Scrum Master líderes que sirven al desarrollo del equipo Scrum a la vez que protegen una cultura basada en los valores de Scrum para ayudar a maximizar la entrega de valor. Los Scrum Masters efectivos trabajan de muchas maneras para mejorar la adopción de Scrum buscando crear confianza y un crecimiento de la autogestión. A contunuación algunas recomendaciones para lograr Scrum Masters efectivos:

Scrum - when done well - actually promotes even greater accountability than waterfall, because the Scrum team is accountable for value delivery. And great Scrum teams measure - and reflect upon - customer outcomes so that they can adjust course and improve their ability to deliver value.

You can't force a team to improve; instead, create the conditions where they want to. Improvement must come from within, and your role as a Scrum Master, leader, or manager is to make that journey possible. In this article, I'll share questions to reflect on and offer tangible recommendations to get started.

In diesem Artikel erklärt PST Simon Flossmann, wie du in 5 Schritten ein Produkt-Ziel definieren kannst.

Surfing holds surprising lessons that correlate to leadership in business and all aspects of life. Today's lesson is about measuring success in complex, unpredictable, and rapidly changing environments.

Struggling with cross-product initiative ownership? Imagine turning complex, strategic bets into streamlined successes with visionary leadership. Discover how product-oriented initiative owners drive outcomes, foster collaboration, and transform challenges into growth opportunities across teams and products.

Many organizations hesitate to hire a dedicated Scrum Master for various reasons, but can Scrum still work without one? Find out in this video with PSTs Robert Pieper, Greg Crown, and Jason Malmstadt.

Leverage the Taskade AI tool to upgrade your Estimation process. It is like a Scrum Team member with a lot of knowledge with which you can have meaningful conversations. So, try it.

An Increment in Scrum must be both useful and usable to deliver value. Explore the differences between these two key qualities, why they matter, and how your Scrum Team can ensure every Increment solves real problems and is ready to be leveraged by users.

Ser un desarrollador efectivo no consiste únicamente en escribir código. Las habilidades para resolver problemas de manera colaborativa y mejorar de manera continua son fundamentales.

So bringen Sie Ihr Produkt-Backlog zur Maximierung der Wertschöpfung für Kunden und Organisation in Ordnung.

Warum „Done“ das Herzstück von Scrum ist In Scrum ist „Done“ weit mehr als nur ein Begriff—es ist das zentrale Konzept, das sicherstellt, dass ein Produktinkrement tatsächlich einsatzbereit ist. Ohne eine klare Definition of Done (DoD) ist empirisches Arbeiten in Scrum unmöglich, da Transparenz, Inspektion und Adaption auf unzuverlässigen Daten basieren würden. Wie beeinflusst „Done“ die Qualität und den Erfolg eurer Sprints? Und warum ist es der Schlüssel für fundierte Entscheidungen und kontinuierliche Verbesserung? In meinem Blog-Post tauche ich tief in die Bedeutung von „Done“ ein und erkläre, warum ohne dieses Konzept der gesamte Scrum-Prozess ins Wanken geraten kann. Jetzt den Blog-Post lesen und herausfinden, wie „Done“ eure Arbeitsweise transformieren kann.

In diesem Artikel teilt PST Simon Flossmann seine beste 3 Workshop-Energizer.

Scrum has been around for almost 30 years now yet there are so many misconceptions about what needs to be done and how it can be done effectively. Even today, as I coach and consult many teams I often see that the purpose of events is mostly lost. And people simply go through the motions, probably to get “checkbox” ticked. For me, Sprint Retrospective is an important event which often is completely misunderstood and is often not very effective. In fact, at times I have seen some teams completely skipping the Retrospective. In this article, I am exploring a common set of dysfunctions I have observed and how can those be countered. I hope you will find it useful.

Many Scrum Masters struggle to coach Product Owners beyond the bounds of the Scrum Guide. This guide offers a practical 30-day approach to building core product management context.

In this vlog, PST Joshua Partogi shares an overview on Evidence-Based Management to measure effectiveness in an organisation, regardless of whether they're using Scrum or Kanban.

Ordering a Product Backlog ensures that every step taken, every backlog item worked, is a step towards delivering value, satisfying stakeholders, and making the best use of the team's capabilities.

Management by exception is the idea that we should manage the things that are off track, rather than giving focus to things that are going well. In the context of the Daily Scrum, this could be done by asking open ended questions intended to find out if there are any issues that need to be discussed.

What gets measured gets managed. But setting OKRs isn't enough. The flow and traction of OKRs need to be managed as well - otherwise, you'll find yourself in the OKR swamp. Using an OKR Kanban can help you both see the swamp and improve the flow and traction of OKRs.

How to Align Teams with Stakeholders, and Finally Fix Your Product Backlog.

In diesem Artikel erklärt PST Simon Flossmann, 5 Problem die Scrum Teams langsam machen.

Surfing holds surprising lessons that correlate to leadership in business and all aspects of life. Today's lesson is about learning through intentional practice.

In Cascais last year at our trainer meetup, we asked, "What are the principles of CAO?" Initially, we saw the Guides in the book as potential principles, but the question stayed with me... Now, back in Cascais for some remote work, I’ve distilled those guides into these principles. Here they are: