Mir ist aufgefallen, wie häufig ich das Format “User Story” zurzeit in diversen Situationen verwende. Dieses agile Werkzeug für die Anforderungsdefinition hat mein Denken infiziert. Dadurch hat es hat meine Kommunikation mit Kollegen verbessert und mir geholfen, mich klarer auszudrücken.
Am Montag schrieb ich an einen bis jetzt unbekannten Kollegen: “Ich benötige Zugriff auf den Ordner, damit ich das alte Angebot mit dem neuen Vorhaben vergleichen kann.” Ich habe den Zugriff sofort bekommen. War er nur hilfsbereit und hatte er gerade Zeit? Oder habe ich ihm durch die Form meines Wunsches geholfen?
Oder: vor einer Woche schrieb ich in einer Powerpoint-Folie für einen Kunden-Workshop eine Reihe von Mitwirkungspflichten in Form von User Stories auf. Beispiel: “Als Dienstleister benötigen wir eine benannte Kundenrolle im Change Prozess, damit wir einen klaren Ansprechpartner haben.” Anstelle der üblichen Diskussionen darüber, ob die Mitwirkungspflichten machbar seien, hat der Kunde spontan allen zugestimmt.
Letztes Beispiel: einem Mitarbeiter wollte ich eine Anweisung geben: “Wenn ich mit dem Kunden darüber spreche, brauche ich ganz aktuelle Statistiken und einige Lösungsvorschlage, damit wir unsere Situation und unsere Verbesserungswillen zeigen können.” Obwohl die Aufgabe relativ aufwändig für den Kollegen war, nahm er sie sofort an, ohne dass ich meine Autorität als Chef ausspielen musste.
Ich nehme aus diesen Erfahrungen folgende Punkte mit:
Was sind User Storys?
User Storys sind inzwischen eine weitverbeitete Technik, um Anforderungen aufzunehmen und zu steuern. Insbesondere nutzen Scrum Teams sie als Hauptinstrument für die Abstimmung, Planung und Steuerung ihrer Arbeit. Die Storys haben eine einfache Form. Aber sie drücken alle wesentlichen Informationen aus, damit ein Entwicklungsteam die Anforderungen von Anwendern umsetzen kann. Ich möchte sie hier nicht vollständig erklären. Für eine gute Einleitung gibt es den Klassiker von Mike Cohn /1/. Aber für die Leser, die sie noch nicht kennen: eine User Story ist ein Satz in folgender Form:Als <Rolle> brauche ich <was ich brauche>, damit <wozu/warum is es brauche>.
Beispiel: “Als Blogger benutze ich einen deutschen Thesaurus, damit ich nach pfiffigen Synonymen suchen kann.”Wie das Entwicklungsteam den Thesaurus für mich umsetzt, bleibt ihm überlassen. Ist eine Story zu groß oder komplex, lässt sie sich in mehrere kleinere Storys leicht herunterbrechen. Als Technik haben User Storys viele Vorteile von Informationsgehalt bis zur Untermauerung der Selbstorganisation im Team. Auch hier gibt es bei Cohn mehr Details /1/.
Persönliche Beispiele
Sie lassen sich auch in weiteren Kontexten anwenden, wie mir über die letzten Wochen bewusst wurde. Drei Beispiele fallen mir spontan ein.Am Montag schrieb ich an einen bis jetzt unbekannten Kollegen: “Ich benötige Zugriff auf den Ordner, damit ich das alte Angebot mit dem neuen Vorhaben vergleichen kann.” Ich habe den Zugriff sofort bekommen. War er nur hilfsbereit und hatte er gerade Zeit? Oder habe ich ihm durch die Form meines Wunsches geholfen?
Oder: vor einer Woche schrieb ich in einer Powerpoint-Folie für einen Kunden-Workshop eine Reihe von Mitwirkungspflichten in Form von User Stories auf. Beispiel: “Als Dienstleister benötigen wir eine benannte Kundenrolle im Change Prozess, damit wir einen klaren Ansprechpartner haben.” Anstelle der üblichen Diskussionen darüber, ob die Mitwirkungspflichten machbar seien, hat der Kunde spontan allen zugestimmt.
Letztes Beispiel: einem Mitarbeiter wollte ich eine Anweisung geben: “Wenn ich mit dem Kunden darüber spreche, brauche ich ganz aktuelle Statistiken und einige Lösungsvorschlage, damit wir unsere Situation und unsere Verbesserungswillen zeigen können.” Obwohl die Aufgabe relativ aufwändig für den Kollegen war, nahm er sie sofort an, ohne dass ich meine Autorität als Chef ausspielen musste.
Ich nehme aus diesen Erfahrungen folgende Punkte mit:
- Die Zugabe des Zwecks schafft Klarheit über das benötigte Objekt. Der Zwerk enthält den Mehrwert und liefert damit dem Empfänger den Sinn. Ist etwas an das Ergebnis oder dessen Grund nicht klar, reichen einfachen Gegenfragen.
- Die Aussagen sind kurz. Die Form diszipliniert mich, die Sache auf das Wesentliche ohne zu reduzieren. Die Kürze entlastet den Empfänger zeitlich und geistig, weil er nicht arbeiten muss, um mich zu verstehen.
- Das Format ist angenehm sachlich. Wie häufig kommen wir in Schwierigkeiten, weil die Aktivitäten und nicht das Ergebnis in Vordergrund gestellt werden./2/
- Ich überlasse dem Empfänger die Lösung sowie deren Planung und Steuerung. Damit bleibt der Empfänger souverän in seiner Selbstorganisation. Kombiniert mit dem ersten Punkt haben wir eine optimale Motivationslage geschaffen: das Ergebnis und die Tätigkeiten ergeben einen Sinn, und der Ausführende entscheidet selbst, wie er sie schafft.
Anmerkungen und Verweise
- /1/ Cohn, Mike: User Stories Applied : For Agile Software Development. 1. Aufl.. Boston: Addison-Wesley Professional, 2004, http://www.mountaingoatsoftware.com/books/user-stories-applied; Einige gute Kurzeinleitungen: https://www.mountaingoatsoftware.com/agile/user-storieshttp://www.ksimons.de/2015/03/user-stories-verstaendlich-erklaert/
- /2/ Warum Aktivitäten-basierte Planung ein Teufelszeug ist findet man hier: http://www.teamworkblog.de/2012/05/aktivitaten-basierte-planung-ist-fur.html
Kommentare
Kommentar veröffentlichen