Scrum ist eine Einstellung. Die fünf Scrum-Werte beschreiben diese Einstellung. Einerseits hilft das Scrum-Rahmenwerk, diese Werte zu entdecken und zu erleben. Andererseits können wir an der Umsetzung des Rahmenwerks auch erkennen, wo unsere Einstellung von den Scrum-Werten abweicht. Mehr dazu im Artikel:

Besser Planung und Aufteilung der Arbeit führt nicht zu mehr Team-Performance. Die individuelle Auslastung von Teammitgliedern führt zu Engpässen. Wie kannst du individuellen Auslastung im Team vorbeugen? Meine bewährte Strategie hierfür findest du im Artikel:

Wenn funktionierende Software kein Garant mehr für Erfolg ist, ist das Manifest für Agile Softwareentwicklung dann noch zeitgemäß?

Seit 2002 ist das Sprint-Ziel Bestandteil von Scrum. Trotzdem verwenden viele Scrum Teams nur selten Ziele. Es kursieren immer noch viele Mythen um Sprint-Ziele, die dazu führen, dass Scrum Teams immer noch damit kämpfen, sich Sprint-Ziele zu setzen. Wenn du erfahren willst, welche Mythen über Sprint-Ziele kursieren und wie du sie widerlegen kannst, dann lies weiter.

Ein Scrum Master zu sein, ist schwer. Es ist genauso schwer, wie guten Code zu schreiben, gut zu zeichnen oder eine Fremdsprache fließend zu sprechen. Der Grund hierfür ist, dass das Meistern jeglicher Fähigkeiten Beständigkeit, Reflexion und bewusstes Handeln erfordert – alles Dinge, für die es dem Durchschnittsmenschen an Engagement fehlt. Hier einige der Herausforderungen, denen ich über die Jahre als Scrum Master mehrfach gegenüberstand und Tipps, wie du diesen begegnen kannst. Ich hoffe, meine Erfahrungen inspirieren dich, damit du dich auch morgen aufs Neue den Schwierigkeiten stellst, die eine Einführung von Scrum mit sich bringt.

Kein UX-Designer im Team? In meinem neuen Artikel findest du 3 einfache Techniken, damit dein Scrum Team noch heute mit UX-Research beginnen kann. Die Erkenntnisse, die dein Team mit diesen Research-Techniken über eure Nutzer erhält, können dir helfen: - User Storys zu schreiben, die wirklich auf wahren „Geschichten“ eurer Nutzer basieren. - Endlose Diskussionen im Sprint-Review mit den Stakeholdern abzukürzen. Jetzt kannst du objektiv begründen, warum das Feature so designt wurde, da nur so die Nutzer bei ihrer täglichen Arbeit entlastet werden. - Im Product Backlog für mehr Übersichtlichkeit zu sorgen, da du die Einträge nach Nutzergruppen bündeln kannst.

Wir sind uns einig, dass wir nicht mit 8 Teams die Entwicklung eines neuen Produkts beginnen sollten, sondern mit einem. Wie skalieren wir dann auf mehrere Teams hoch, wenn wir an Entwicklungsgeschwindigkeit gewinnen wollen? Vier bewährte Strategien, wie die Skalierung gelingen kann.

Ich habe in den letzten 7 Jahren mit vielen Scrum Teams gearbeitet und bei keinem Team war das Refinement gleich. In jedem Team haben sich die Refinement-Praktiken, die funktioniert haben, mit der Zeit verändert. Hier, findest du meine 4 wichtigsten Lektionen.

Mehrere Product Owner führen zu verzögerten Entscheidungen. Nur ein Product Owner ist ein Garant dafür, dass Entscheidungen schnell getroffen werden und somit das Unternehmen agil bleibt. Wie deskaliert man die Product-Owner-Verantwortung zurück auf eine Person? Hier meine Schritt-für-Schritt-Anleitung.

Viele agile Teams sind in der Lage, regelmäßig Software zu liefern. Sie stoßen jedoch an Grenzen, wenn es um die Festlegung von Zielen, die Bestimmung von Prioritäten und die Messung von Fortschritten innerhalb der Organisation geht. 

Viele angehende Scrum Master erzählen mir im Professional Scrum Master Training, dass sie es schwierig finden, diese vier Dinge zu vereinen. Hier 3 Tipps, wie ich diese Situation in der Vergangenheit gemeistert habe.

Schon seit Jahren beobachte ich bei Scrum Teams dieses Phänomen: Die Einträge im Sprint Backlog bewegen sich tagelang gar nicht. Und dann wird in letzter Minute doch alles fertig. 

Im 15. State of Agile Report berichten nur 23 % der Befragten, dass sie Lean-UX-Praktiken in agilen Teams anwenden. 

Wir sind uns einig, dass die Entwicklung von Features nicht den Beginn eines Entwicklungsvorhabens darstellen sollte. 

Was haben eine Agile Transformation, die Dienstleistung einer Personalabteilung und ein Softwareprodukt gemeinsam?

Die neue Art, im digitalen Zeitalter über Produktmanagement nachzudenken, besteht darin, das Produkt als eine Data-Mining-Maschine zu sehen.

Produktentwicklung ist komplex. Scrum Master sind Manager dieser Komplexität.

Wenn dein Team auch Probleme damit hat, gute Sprint-Ziele zu formulieren, dann lass mich dir mein Rezept geben. Es wird dir eine Menge Zeit ersparen.

Bei der Skalierung von Scrum balancieren wir Kosten und Aufwand mit Nutzen und Vorteilen. Kosten und Aufwand werden durch zusätzliche Teams verursacht.

Ich bringe Teams bei, wie sie UX-Praktiken und Scrum verbinden können.

Nicht nur Google, Amazon und Spotify verwenden sie, sondern auch viele andere erfolgreiche Produktorganisationen. Die Rede ist von Objectives and Key Results (OKRs).

Es war Weihnachten 2011. Wie in jedem Jahr verbrachten die Menschen die Feiertage im Kreis ihrer Familie und ihrer Liebsten und hielten diese Momente auf Fotos fest.

Scrums größte Stärke ist dessen Einfachheit, welche aber auch die Quelle vieler Mythen und Fehlinterpretationen ist.

Als ich 2015 das erste Mal von Velocity in der Softwareentwicklung gehört habe, war ich begeistert. 

Jedes Scrum Team sollte einen UX-Experten besitzen. 

„Warum müssen wir unsere Arbeitsweise ändern? Ich bin Führungskraft in einem durchschnittlichen Unternehmen und nicht in einem Tech-Giganten im Silicon Valley.“ 

Als Steward für das Scaled Professional Scrum mit Nexus Training habe ich vor einiger Zeit an einer

Im Jahr 2022 ist Scrum inzwischen Mainstream – und dank des Erfolgs von Produkten wie dem iPhone von Apple, dem Kindle von Amazon oder der Suche von Google gilt dasselbe auch für User Experience.

Es gibt zwei Arten von Product Ownern...

Produktentwicklung beginnt und endet mit Produktentdeckung.

Da ich bereits „Scrum Master“ bin, dachte ich, ich wäre bereits ein guter Facilitator.

Was ist Product Backlog Refinement?

Eine lineare, schrittweise Abfolge von Änderungen — in der Regel durchgeführt von funktional getrennten Abteilungen — ist völlig unvereinbar mit der Änderungsgeschwindigkeit und Komplexität moderner Softwareprodukte.

In jedem Professional Scrum Product Owner Training werden die gleichen 10 Fragen gestellt. Und das zu Recht! Das sind die Dinge, mit denen die Teilnehmer am meisten zu kämpfen haben.

Wie können Scrum Teams in ihrer Entwicklungsarbeit den Nutzer niemals aus dem Auge verlieren? Hier 3 einfache Praktiken, die sie von YouTube, LinkedIn, Microsoft lernen können.

Über 100 Jahre Industriezeitalter haben uns gelehrt, dass die Lieferung von Produkten den Erfolg eines Unternehmens bestimmt.

Wann ist das Feature fertig? Diese legitime Frage, die Stakeholder im Sprint Review stellen und welche regelmäßig Mitglieder des Scrum Teams zusammenzucken lässt, sollte jeder erfahrene Product Owner beantworten können.

Hier mein bewährtes Rezept, wie Product Owner das Sprint Review zu einem gemeinschaftlichen Arbeitstermin machen können und nicht zu einer Demonstration, Präsentation oder Feature-Abnahme verkommen lassen.

Eine bewährte Anleitung, wie Du als angehender Product Owner ein Sprint Planning in Jira durchführst

German blog on 5 lessons that I learned in the first year as a product owner that can save you a lot of time and frustration

Hochperformante Teams, die vorhersagbar liefern, tragen maßgeblich zum Erfolg von Unternehmen bei.

Das Problem mit Features ist, dass sie fertiggestellt und ausgeliefert werden sowie perfekt funktionieren, aber dennoch keinen Wert liefern können.

Häufiges Feedback ist der Motor, meine Schulungen ständig zu verbessern.

Ungeplante Arbeit ist die Regel und nicht die Ausnahme.

Scrum of Scrums describes one of the first approaches to scale Scrum and is often confused with Nexus Daily Scrum.  

In this blog post, we discuss how team size and organization can be considered when scaling Scrum.

How effectively a Nexus works depends on its ability to eliminate dependencies. Eliminating dependencies simplifies integration. Scrum Masters who efficiently perform cross-team refinements save time. Saving time saves money. 

When scaling Scrum, we balance cost and effort with benefits and advantages. Costs and effort come from adding teams. Benefits and advantages come from delivering more value in the same amount of time. 

Organizations need to move fast and receive ongoing feedback from customers to drive sustainable innovation through continuous discovery and value delivery. But there is a problem — dependencies.

Scrum Teams do it all the time. It happens in Sprint Review, after Daily Scrum, in Sprint Planning, and as part of development. They discuss the upcoming work to gain a shared understanding...