Agile RE/BA kommt. Dennoch wird weiterhin viel Ausschuss produziert. Als Agile RE/BA muss man Ausschuss vermeiden. In diesem Blog-Beitrag liste ich die sieben Arten von Verschwendung (Muda) im Agile RE/BA.
Ein komplettes Kapitel im Lehrplan des Certified Agile Business Analyst (CABA) beschäftigt sich mit waste. Darin purzeln Stichwörter wie Einfachheit, Just in Time Spezifikation, Leichtgewichtigkeit und so weiter. Das offenbart eine Verwandtschaft mit der Lean-Bewegung. Dieser Verwandtschaft forsche ich nach. Ich übersetze die klassischen sieben Arten der Verschwendung auf unsere Tätigkeiten im Agile RE/BA.
Typische Beispiele von Verschwendung in der Produktion
Der Erfinder des Toyota-Produktionssystems (TPS) identifizierte sieben Arten der Verschwendung, die ermuda nannte, auch gerne übersetzt als waste. Typische Beispiele sind:
Verschwendung | Beispiele in der Produktion |
|---|---|
| Überproduktion |
|
| Zu hohe Lagerbestände |
|
| Unnötige Transporte |
|
| Wartezeit/Liegezeit |
|
| Reparaturen/Fehler |
|
| Wegezeiten/Unnötige Bewegungen |
|
| Flächen |
|
Beispiele im Agile RE/BA
Diese sieben Arten können auch für uns Agile RE/BA übersetzt werden. Diese Beispiele gründen auf meinen Erfahrungen als Agile RE/BA in skalierten agilen Projekten. Sie sind weder vollzählig noch abschliessend.
Überproduktion
Du verwendest keine just in time Spezifikation? Du spezifizierst Backlog Items, die niedrig priorisiert sind? Du diskutierst mit Stakeholder über Endzustände einer fernen Zukunft? Du dokumentierst, was niemand in nachgelagerten Aktivitäten (Entwicklung, Testing, Betrieb) benötigt?
Zu hohe Lagerbestände
Du detaillierst regelmässig zu viele Backlog Items? Backlog Items, welche regelmässig nicht in einem Sprint verpackt werden (können)? Details, die du regelmässig wieder aktualisieren musst, die aber nicht verwendet werden?
Du hortest Dokumentationen, die du nicht nachhaltig weiterentwickeln kannst oder willst? Geschäftsfälle einer fernen Zukunft oder einer längst überkommenen Vergangenheit? Du lagerst Ideen, Verbesserungen "in weiser Voraussicht"?
Unnötige Transporte
Du beteiligst zu viele Stakeholder beim Ermitteln, Prüfen und Abstimmen? Du beteiligst die falschen Stakeholder, die nicht prüfen, abnehmen können?
Du streust zu viele Informationen, die verunsichern, Rückfragen und Verwirrung provozieren? Ebenso: du kommunizierst kreuz und quer? Einmal mündlich, dann per Email, dann per Lync? Du bevorzugst Emails statt direkte Kommunikation? Schliesslich: du verzettelst dich in Widersprüchen, die du wieder korrigieren musst - und damit noch mehr Bewegung erzeugst?
Du verwaltest deine Backlog Items und Dokumentationen in vier unterschiedlichen Tools? Einmal Post-It, JIRA, HP ALM und Excel?
Du spielst Proxy PO, weil dein PO aufgrund Zeitmangels seine Aufgaben nicht wahrnehmen kann?
Wartezeit/Liegezeit
Du kannst deine Spezifikation nicht "vollenden", weil Informationen oder Entscheidungen fehlen? Dein Fachbereich brütet über Produktvisionen und -strategien, aber kann sie nicht abschliessen? Dein Stakeholder ziert sich gänzlich? Oder andersherum: Stakeholder, die du abholen musst, aber keinen Wert liefern, bremsen dich aus?
Du kannst Thesen nicht testen, weil du die Implementation abwarten musst? Du kannst - aus welchen Gründen auch immer - nicht prototypen?
Reparaturen/Fehler
Du hast einen Stakeholder vergessen und musst daher deine Spezifikation überarbeiten? Du hast eine Lösung skizziert, die nicht mit der Gesamtarchitektur abgestimmt ist? Oder du hast eine Anforderung übersehen?
Du hast ein Backlog Item unklar spezifiziert und musst daher häufiger Rückfragen der Entwickler und Tester beantworten?
Oder zum Beispiel mein Liebling:
Du hast in "weiser Voraussicht" eine vermeintliche Verbesserung in deine Spezifikation hineingeschmuggelt, die aber wieder kostspielig entfernt werden muss, weil sie nicht den vermeintlichen Nutzen bringt?
Du ignorierst alle Buchstaben des Mnemoniks INVEST beim Beschreiben deiner Backlog Items? Fehler, die irgendjemand später korrigieren muss? Zum Beispiel:
- Du vermengst Backlog Items, damit sie nicht abgrenzbar sind? - (Independent)
- Du verhärtest den Endzustand der Lösung in dem Backlog Item, das die Diskussion im Entwicklungsteam hemmt? - (Negotiable)
- Du forderst Backlog Items, die erwiesenermassen keinen direkten oder indirekten Nutzen stiften? - (Valuable)
- Du formulierst Backlog Items, die niemand einschätzen kann, welche verwirren und verunsichern? - (Estimable)
- Du schneidest Backlog Items so gross, dass sie nicht in einer Iteration fertiggestellt werden können? Für diese Erkenntnis verschwendest du eine Iteration? - (Small)
- Du verfasst unmögliche, weil nicht testbare Backlog Items, die dadurch nicht richtig erledigt werden können? - (Testable)
Wegezeiten/Unnötige Bewegungen
Du reist zu viel zu deinen Stakeholder? Du verwendest zwei unterschiedliche Sprachen, um Backlog Items zu beschreiben? Oder konkreter: du verwendest einmal Aktivitätsdiagramme, einmal BPMN und einmal Flow Charts, um zum Beispiel Prozesse zu beschreiben? Du mischst darin unterschiedliche Fachbegriffe?
Ein Klassiker:
Du selber bist nicht agil, aber das Entwicklungsteam soll es sein, ohne Agile RE/BA?
Flächen
Du musst eine veraltete IT-Infrastruktur nutzen, welche dich bei deiner täglichen Arbeit mehr blockiert als unterstützt? Du nutzt fette Tool-Suiten statt best of breed? Oder deine Entwicklungsprozesse sind unklar und sehr spekulativ? Eventuell ist gar das Projektvorgehen nicht definiert?
Wer erkennt sich wieder?
Hast du auch Beispiele klassischer Verschwendungen in deinem (agilen) Projekt? Dann teile sie mit uns! Wir wollen niemanden anschwärzen oder belehren. Denn auch ich muss mich ertappen, wie ich Ausschuss produziere und damit den Business Value meines Kunden gefährde. In einem späteren Folgebeitrag werde ich euch einige Praxistipps präsentieren, wie man Muda im Agile RE/BA rasch und einfach vermeiden kann.