Vor einiger Zeit durfte ich Zeuge werden folgender, kaskadierter Kommunikation, welche zu allem Überfluss auch noch vollständig per Email stattfand.
Anwender beim Kunden zu seinem Projektmanager: “Ich will nicht immer in den Daten meines Kollegen arbeiten müssen, geht das irgendwie?”
Projektmanager des Kunden zum Sales Manager des Auftragnehmers: “Unterstützt das Produkt eine Art Benutzerlogin, damit die Daten der einzelnen Anwender getrennt bleiben?”
Sales Manager zum Produktmanager: “Der Kunde benötigt dringend eine Benutzerverwaltung, wie schnell bekommen wir das umgesetzt?”
Produktmanager zum Chief Product Owner: “Ohne richtige Benutzerverwaltung werden wir den Kunden verlieren! Wann können wir die liefern?”
Chief Product Owner zum Product Owner: “Es gibt eine neue Story ‘Benutzerverwaltung’. Bitte kümmere Dich schnellstens drum, ich stelle sie an die oberste Stelle für Dein Backlog.”
Product Owner zum Entwicklungsteam: “Ich habe drei neue User Stories für Euch. Wir brauchen eine typische Benutzerverwaltung mit folgenden Stories. Als Administrator möchte ich Benutzer anlegen und diesen Funktionen und Rechte zuweisen, damit nicht alle Anwender auf alle Bereiche zugreifen können. Als Anwender möchte ich mich einloggen und meine persönlichen Einstellungen verändern, damit ich das Aussehen der Anwendung auf meine Vorlieben anpassen kann. Als Administrator möchte ich Benutzergruppen verwalten, damit ich nicht jedem einzelnen Anwender Rechte zuweisen muss.”
Frage der Entwickler: “Sollen die Anwender auf alle Daten zugreifen können oder nur auf ihre eigenen?”
Antwort des Product Owner: “Nein, das wird auf keinen Fall benötigt. Ich möchte, dass die Anwender sich einloggen müssen, aber jederzeit mit allen Datensätzen arbeiten können.”
Was können wir aus dieser Geschichte lernen? Wenn wir uns die agilen Werte, Prinzipien und Praktiken ansehen, gibt es mehrere Aspekte, die hier schief gelaufen sind.
- Einfachheit (Simplicity) – Anstelle der einzig sinnvollen User Story “Als Anwender möchte ich nur auf meine eigenen Daten zugreifen können, um nicht in den Daten meines Kollegen arbeiten zu müssen” wurden drei User Stories erfunden, welche mit dem tatsächlichen Anwendernutzen nur noch sehr entfernt etwas zu tun haben.
- Kommunikation (Communication) – Wir können nicht unterstellen, dass Kommunikation nicht stattgefunden hat. Sie war nur sehr einseitig und wurde direkt interpretiert und weitergeleitet ohne dass ein Dialog zwischen den Beteiligten zustande kam.
- Aktive Einbindung der Anwender (Active User Involvement) – Der echte Anwender hätte mindestens direkt mit dem Product Owner kommunizieren sollen, besser noch mit dem Entwicklungsteam. Statt dessen gab es fünf Informationsvermittler zwischen Anwender und Team.
- Business Value – Für den Auftragnehmer ist durch die entstandene Beauftragung zumindest ein monetärer Wert entstanden. Wenn wir Business Value jedoch als Kundennutzen interpretieren, dann wird nicht der geringste Wert geliefert, da der Anwender immer noch nicht so mit dem System arbeiten kann, wie er es gerne hätte.
- Verschwendung erkennen und eliminieren (Seeing Waste, Eliminate Waste) – An vielen Stellen in der Kommunikation wäre die Frage notwendig gewesen: “Wofür ist das gut?” Wenn wir den “in order to”-Teil einer User Story nicht zweifelsfrei beantworten können, laufen wir Gefahr, unnütze Features umzusetzen, welche den Anwender nicht glücklich machen und dafür Zeit, Aufwand und Geld kosten. Waste in Reinform. Nicht nur die unnötigen User Stories müssen wir als Waste identifizieren, auch die fünf unnötigen Zwischenstufen in der Kommunikation sind reine Verschwendung.
Mein Fazit lautet: der einfachste Weg funktioniert am besten. Durch die kontinuierliche Einbindung der echten Anwender in ein Team und die konsequente Beantwortung der “wofür ist das gut”-Frage sorgen wir dafür, den größtmöglichen Kundennutzen mit der einfachsten Lösung ohne große Missverständnisse zu erzeugen und das ohne die geringste Verschwendung.