Ein Agile-Prozessverbesserungsworkshop ist eine fokussierte Sitzung, in der ein Team seine Arbeitsweise ändert. Er beginnt mit einer beobachteten Schwierigkeit, prüft konkurrierende Erklärungen und endet mit einer testbaren Änderung. Das Ergebnis ist keine lange Wunschliste, sondern eine Entscheidung, die das Team umsetzen und überprüfen kann.
Der Workshop kann Teil einer Retrospektive sein oder separat stattfinden, wenn ein Problem eine vertiefte Untersuchung erfordert. Im Scrum nennt der Scrum Guide die Verbesserung von Qualität und Effektivität als Zweck der Sprint-Retrospektive. Das folgende Format ist ein Moderationsvorschlag, kein zusätzlich verpflichtendes Scrum-Ereignis.
Für den größeren Rahmen nutzen Sie den Leitfaden zur Sprint-Retrospektive. Dieser Workshop ist enger gefasst: ein folgenreiches Muster in der Arbeit und ein gezielter Test.
Ein Problem wählen, das die Gruppe beeinflussen kann
Beginnen Sie mit einer Beobachtung, nicht mit einer Lösung. „Prüfungen bleiben bis Freitag liegen“ lädt zur Untersuchung ein. „Wir brauchen ein weiteres Freigabetool“ setzt einen bevorzugten Kauf voraus, bevor die Gruppe die Verzögerung versteht.
Beschreiben Sie die Auswirkungen auf die Arbeit: Wartezeit, Nacharbeit, verspätetes Feedback, vermeidbares Risiko oder eine unklare Entscheidung. Nennen Sie die betroffenen Personen und den betrachteten Zeitraum. Verwenden Sie keinen Personennamen als Problemdefinition.
Klären Sie die Entscheidungsrechte. Kann die Gruppe die betreffende Richtlinie oder Abhängigkeit nicht ändern, kann sie eine Empfehlung vorbereiten; das ist aber ein anderes Ergebnis als ein selbst genehmigtes Experiment. Laden Sie die zuständige Person ein oder legen Sie den Eskalationsweg fest.
Wählen Sie wenige Fälle aus. Drei gut verstandene Beispiele können ein nützliches Gespräch ermöglichen, beweisen aber nicht, wie oft das Muster bei allen Arbeiten auftritt. Benennen Sie die Grenzen der Belege.
Belege vorbereiten, ohne Überwachung daraus zu machen
Bringen Sie Informationen zur Arbeit mit: Übergabetermine, Warteschlangenstatus, wiedereröffnete Aufgaben, Entscheidungsprotokolle und vereinbarte Qualitätsprüfungen. Verwenden Sie passende Zusammenfassungen und Verweise, statt vertrauliche Inhalte auf ein Workshop-Board zu kopieren.
Bitten Sie die Teilnehmenden, vor dem Treffen Kontext hinzuzufügen. Ein Zeitstempel eines Tickets kann zeigen, wann sich ein Status änderte, nicht warum das Team warten musste. Eine eindrückliche Geschichte kann umgekehrt unvergesslich, aber nicht repräsentativ sein.
Halten Sie Kennzahlen auf dem Niveau, das für den Prozesstest nötig ist. Personen anhand von Aktivitätszahlen zu vergleichen, kann vom gemeinsamen System ablenken und defensive Erklärungen fördern. Muss individuelles Verhalten angesprochen werden, nutzen Sie dafür den passenden separaten Prozess.
Erklären Sie, was mit den Notizen geschieht und wer sie sehen kann. Beteiligung lässt sich besser einordnen, wenn klar ist, ob ein Lernprotokoll des Teams oder ein Bericht für die Führung erstellt wird.
Agenda für einen 60-minütigen Workshop
| Zeit | Aktivität | Benötigtes Ergebnis |
|---|---|---|
| 0–8 Minuten | Problem, Grenze und Belege vereinbaren | Eine beobachtungsorientierte Problemdefinition |
| 8–20 Minuten | Repräsentative Fälle durchgehen | Gemeinsamer Bericht über Verzögerung oder Fehler |
| 20–32 Minuten | Erklärungen erst einzeln, dann gemeinsam entwickeln | Plausible Ursachen und offene Fragen |
| 32–45 Minuten | Kleine Eingriffe vergleichen | Eine Änderung mit ausdrücklich benanntem Zielkonflikt |
| 45–55 Minuten | Experiment und Schutzmaßnahmen definieren | Verantwortliche, geeignete Fälle, Belege und Prüfauslöser |
| 55–60 Minuten | Verständnis und Kapazität prüfen | Akzeptierte Zusage und sichtbarer nächster Schritt |
Lassen Sie die Agenda keine voreilige Schlussfolgerung erzwingen. Reichen die Belege nicht, planen Sie eine begrenzte Untersuchung mit verantwortlicher Person und Entscheidungsdatum. „Herausfinden, wo diese Fälle warteten“ ist ein gültiger nächster Schritt; „Zusammenarbeit verbessern“ ist nicht konkret genug.
Laden Sie stillere Teilnehmende ein, vor dem Gespräch schriftlich zu antworten. Fragen Sie, was die bevorzugte Erklärung der Gruppe widerlegen könnte. Eine Mehrheitsabstimmung kann ein Anliegen priorisieren, aber keine Ursache beweisen.
Beispiel: Prüfungen sammeln sich am Ende der Woche
Dieses hypothetische Beispiel nutzt erfundene Beobachtungen und Testgrößen.
Ein Team sieht mehrere Aufgaben, die bis Freitag auf Prüfung warten. Die erste Erklärung lautet, die Prüfenden seien zu beschäftigt. Die Betrachtung von sechs aktuellen Aufgaben zeigt ein genaueres Muster: Prüfungsanfragen enthalten weder eine klare Frage noch einen Hinweis darauf, was sich gegenüber der vorherigen Version geändert hat.
Das beweist nicht, dass die Anfragequalität die einzige Ursache ist. Das Team erkennt außerdem begrenzte Verfügbarkeit der Prüfenden und eine späte externe Abhängigkeit. Es wählt die Hypothese zur Anfragequalität, weil sie sich ohne Personaländerung oder Umgehung der Prüfung testen lässt.
Bei den nächsten acht geeigneten Prüfungen ergänzt die erstellende Person eine kurze Änderungsübersicht, die benötigte Entscheidung und bekannte Risiken. Die prüfende Person bestätigt vor Beginn, ob die Angaben ausreichen. Bestehende Qualitäts- und Freigabeanforderungen bleiben bestehen.
Das Team erfasst die Wartezeit auf Rückfragen und untersucht zwei abgeschlossene Prüfungen. Als Schutzregel gilt, dass die Übersicht nicht zu einem Dokument werden darf, dessen Erstellung mehr Aufwand verursacht als die Prüfung selbst.
Nach dem achten Fall oder nach zwei Wochen – je nachdem, was zuerst eintritt – entscheidet das Team, ob es die Praxis beibehält, anpasst oder beendet. So lässt sich der Test überprüfen, selbst wenn weniger Arbeit als erwartet anfällt.
Eine Experimentkarte erstellen, die wirklich genutzt wird
Halten Sie Folgendes in einem kurzen gemeinsamen Protokoll fest:
Beobachtung: Was geschah in den ausgewählten Fällen?
Hypothese: Warum könnte die Änderung das Muster verbessern?
Änderung: Welches Verhalten oder welcher Prozess wird anders?
Umfang: Welche Fälle sind ein- oder ausgeschlossen?
Verantwortliche Person: Wer koordiniert den Test und sammelt Belege?
Schutzregel: Was darf sich nicht verschlechtern?
Prüfung: Welche Belege und welches Datum stützen Beibehalten, Anpassen oder Beenden?
Trennen Sie die verantwortliche Person für das Experiment von den Personen, die die veränderte Arbeit ausführen sollen. Alle Betroffenen müssen die Bitte verstehen; externe Beteiligte müssen ihren Beitrag akzeptieren, statt nach dem Treffen zugewiesene Aufgaben zu erhalten.
Legen Sie das Experiment dort ab, wo normale Arbeit geplant wird. Eine Karte auf einem Workshop-Board kann leicht vergessen werden, wenn der Lieferdruck zurückkehrt. Verknüpfen Sie das Lernprotokoll mit der vorhandenen Aufgaben- oder Planungsverwaltung des Teams.
Erkenntnisse prüfen, ohne das Ergebnis zu übertreiben
Vergleichen Sie bei der Überprüfung den tatsächlichen Verlauf mit den Erwartungen. Wurde die Änderung angewendet? Änderte sich das relevante Warteproblem? Bewegte sich gleichzeitig ein anderer Faktor? Was fanden die Beteiligten nützlich oder belastend?
Ein kleiner Vorher-nachher-Test kann eine lokale Entscheidung stützen, ohne einen allgemeinen ursächlichen Zusammenhang zu beweisen. Benennen Sie die Unsicherheit. Wirkt die Praxis hilfreich, aber die Beleglage ist dünn, führen Sie sie für einen festgelegten Zeitraum fort, statt einen großen Produktivitätsgewinn zu behaupten.
Beenden Sie Änderungen, deren Kosten ihren Nutzen übersteigen. Verbesserungsarbeit konkurriert mit anderer Arbeit und sollte derselben Wertfrage standhalten. Ein Workshop ist erfolgreich, wenn er eine begründete Entscheidung hervorbringt – auch die Entscheidung, eine Idee nicht fortzusetzen.
Nutzen Sie bei Bedarf andere Retrospektiven-Ideen und den Leitfaden zu Retrospektiven-Maßnahmen, um die nächste Prüfung festzulegen.
Häufige Fragen
Unterscheidet sich dieser Workshop von einer Retrospektive?
Er kann Teil davon sein. Eine Retrospektive kann die jüngste Teamarbeit umfassender betrachten; dieser Workshop konzentriert sich auf ein konkretes Prozessproblem und einen Eingriff. Setzen Sie kein zusätzliches Treffen an, wenn das bestehende Ereignis die Aufgabe erfüllt.
Wie viele Verbesserungen sollte das Team auswählen?
Wählen Sie nur so viele, wie das Team verantwortungsvoll umsetzen und bewerten kann. Mit einer bedeutsamen Änderung zu beginnen, macht Belege oft leichter interpretierbar. Wichtiger als eine feste Quote sind verfügbare Kapazität und klare Verantwortung.
Was, wenn die Ursache außerhalb des Einflussbereichs des Teams liegt?
Bereiten Sie für die zuständige Person einen konkreten Antrag oder eine Empfehlung mit Belegen und der benötigten Entscheidung vor. Versprechen Sie kein Experiment, das das Team nicht genehmigen kann. Wählen Sie, soweit möglich, eine lokale Abhilfe, während die umfassendere Entscheidung aussteht.