Ich persönlich habe u.a. mit Event Storming und User Story Mapping Workshops mit klarem Fokus auf die Stärkung des agilen Mindsets gute Erfahrungen gemacht und hohe Return on Time Invested (ROTI) erzielt. Welche Methoden habt Ihr schon eingesetzt, die gut angekommen sind und wie hoch war ggf. der ROTI?
1 Antwort
Zunächst: wenn das Umfeld keine Fehlerkultur kennt, dann wird es auch mit dem Mut schwierig werden, sich ein anspruchsvolles Sprintziel zu setzen. Dies zeigt sich dann meist darin, dass die Sprintziele ohne größere Risiken erreichbar sind. Das bedeutet gleichzeitig, dass eigentlich mehr geht.
Ich habe gute Erfahrungen damit gemacht, wenn das Team dem wirklichen Kunden so nah wie möglich steht. Dies sorgt dafür, dass das Team hautnah miterlebt, was die Erwartungshaltung des Kunden ist. Meine Erfahrung hat mir gezeigt, dass zumeist alle Mitarbeiter dem Kunden gegenüber immer eine gute Figur machen möchten. Insofern, wenn ein Kunde seine Enttäuschung ausdrückt, dass nicht mehr erreichbar ist oder wurde, dann wird ein Team aus sich selbst heraus mit hoher Wahrscheinlichkeit versuchen, mehr aus sich herauszuholen.
Andererseits habe ich die Erfahrung gemacht, dass zwar Story Mapping und Event Storming sehr gut geeignet sind, gute Sprintpläne zu erarbeiten, die fokussiertes Arbeiten erlauben. Gleichzeitig aber das Commitment für ein anspruchsvolles Sprintziel dennoch nicht gegeben ist. Es reicht nicht aus, wenn z.B. NUR ein Releaseplan erreicht werden will und dieser Releaseplan von der Projektleitung oder der Führungsebene kommuniziert wird, die von den Teams (zwar nicht offensichtlich, aber insgeheim) womöglich negiert wird. Dies schafft kaum Eigenmotivation. Ein enttäuschter Kunde hingegen schon eher.
Was auch hilft, wenn im Sprint-Review möglichst der Kunde selbst, sowie auch Leute aus der Führungsebene und Projektleitung anwesend sind. Das sollte eigentlich selbstverständlich sein, ich erlebe es aber oft anders. Damit einhergehend wird auch ein Team sein Sprintziel nicht so ernst nehmen, wenn es scheinbar 'Niemanden' interessiert, was man im Sprint erreicht hat. Diese gruppendynamische Erkenntnis und Wirkung auf die Motivation eines Teams sind in der Organisation oft nicht bekannt oder werden daher nicht ernstgenommen und folglich geht die nicht unerhebliche Wirkung für die Organisation verloren. Um ein Bewusstsein in der Organisation dafür zu schaffen, reicht es manchmal schon aus, diese wichtige Erkenntnis auszusprechen. Jeder Mensch ist in der Lage, diesen Sachverhalt emotional nachzuvollziehen.
Ich habe Scrum Master erlebt, die die Meinung vertreten haben, man dürfe ein Team nicht drängen, schließlich hätte das eine schädliche Wirkung auf die Motivation. Ich stimme dem nicht zu. Vielmehr bin ich der Meinung, dass es unbedingt notwendig ist, das Enttäuschung gezeigt wird, wenn Enttäuschung da ist. Allerdings wäre es eine wenig zielführende Folgemaßnahme, daraus den Teams zu sagen, ihr 'müsst' jetzt dies und das erreichen.
Hingegen kann der Scrum Master z.B. nach einem Review, indem der Kunde seine Enttäuschung geäußert hat in der anschließenden Retrospektive mit dem Team an Ideen arbeiten, wie man wieder glückliche Gesichter beim Kunden erreichen kann. Z.B. indem man für die Folgesprints viel enger mit dem Kunden (mindestens vertreten durch den PO) von vorne herein Erwartungshaltungen für den Sprint klärt und sich gemeinsam festlegt, was möglich sei und wo auch Risiken liegen. Dies fördert den Mut des Teams, sich mehr zuzutrauen, gerade weil man gemeinsam das Sprintziel erarbeitet hat.
Ich habe gute Erfahrungen damit gemacht, wenn das Team dem wirklichen Kunden so nah wie möglich steht. Dies sorgt dafür, dass das Team hautnah miterlebt, was die Erwartungshaltung des Kunden ist. Meine Erfahrung hat mir gezeigt, dass zumeist alle Mitarbeiter dem Kunden gegenüber immer eine gute Figur machen möchten. Insofern, wenn ein Kunde seine Enttäuschung ausdrückt, dass nicht mehr erreichbar ist oder wurde, dann wird ein Team aus sich selbst heraus mit hoher Wahrscheinlichkeit versuchen, mehr aus sich herauszuholen.
Andererseits habe ich die Erfahrung gemacht, dass zwar Story Mapping und Event Storming sehr gut geeignet sind, gute Sprintpläne zu erarbeiten, die fokussiertes Arbeiten erlauben. Gleichzeitig aber das Commitment für ein anspruchsvolles Sprintziel dennoch nicht gegeben ist. Es reicht nicht aus, wenn z.B. NUR ein Releaseplan erreicht werden will und dieser Releaseplan von der Projektleitung oder der Führungsebene kommuniziert wird, die von den Teams (zwar nicht offensichtlich, aber insgeheim) womöglich negiert wird. Dies schafft kaum Eigenmotivation. Ein enttäuschter Kunde hingegen schon eher.
Was auch hilft, wenn im Sprint-Review möglichst der Kunde selbst, sowie auch Leute aus der Führungsebene und Projektleitung anwesend sind. Das sollte eigentlich selbstverständlich sein, ich erlebe es aber oft anders. Damit einhergehend wird auch ein Team sein Sprintziel nicht so ernst nehmen, wenn es scheinbar 'Niemanden' interessiert, was man im Sprint erreicht hat. Diese gruppendynamische Erkenntnis und Wirkung auf die Motivation eines Teams sind in der Organisation oft nicht bekannt oder werden daher nicht ernstgenommen und folglich geht die nicht unerhebliche Wirkung für die Organisation verloren. Um ein Bewusstsein in der Organisation dafür zu schaffen, reicht es manchmal schon aus, diese wichtige Erkenntnis auszusprechen. Jeder Mensch ist in der Lage, diesen Sachverhalt emotional nachzuvollziehen.
Ich habe Scrum Master erlebt, die die Meinung vertreten haben, man dürfe ein Team nicht drängen, schließlich hätte das eine schädliche Wirkung auf die Motivation. Ich stimme dem nicht zu. Vielmehr bin ich der Meinung, dass es unbedingt notwendig ist, das Enttäuschung gezeigt wird, wenn Enttäuschung da ist. Allerdings wäre es eine wenig zielführende Folgemaßnahme, daraus den Teams zu sagen, ihr 'müsst' jetzt dies und das erreichen.
Hingegen kann der Scrum Master z.B. nach einem Review, indem der Kunde seine Enttäuschung geäußert hat in der anschließenden Retrospektive mit dem Team an Ideen arbeiten, wie man wieder glückliche Gesichter beim Kunden erreichen kann. Z.B. indem man für die Folgesprints viel enger mit dem Kunden (mindestens vertreten durch den PO) von vorne herein Erwartungshaltungen für den Sprint klärt und sich gemeinsam festlegt, was möglich sei und wo auch Risiken liegen. Dies fördert den Mut des Teams, sich mehr zuzutrauen, gerade weil man gemeinsam das Sprintziel erarbeitet hat.
Noch ein anschauliches Beispiel zum Thema 'nah am Kunden' sein:
Ein Product Owner (für Fahrradverleih) gibt seinem Team folgende Aufgaben mit in den Sprint: Es sollen bei 3 Fahrrädern die Reifen gewechselt und bei weiteren 5 die Ketten gereinigt und geschmiert werden. Was könnte ein Sprintziel sein? Z.B. "Alle Fahrräder sind in gewartetem Zustand".
Ehrlich? Macht mich nicht an, sorry! Ist fade, stupide und solala halt. Wird ein Team alles darum geben, dieses Sprintziel zu erreichen und das Äußerste aus sich herauszuholen? Eher nicht.
Die Frage nach einem anspruchsvollem Sprintziel ist also gar nicht so leicht. Das Problem ist jedoch systemisch bedingt und ein anspruchsvolles Sprintziel kann erst gar nicht entstehen, weil dem Team das eigentliche Kundenproblem nicht bekannt ist.
Das führt uns zur richten Frage: Wie kann das Team besser über das echte 'Problem des Kunden' und nicht das des PO informiert sein? Recht simpel: Indem das Team bereits bei der Anforderungsaufnahme (zumindest in Teilen) dabei ist. Hätte nämlich das Team Zugang zum wirklichen Kunden gehabt, wäre Folgendes passiert:
Ein Teamvertreter geht mit dem PO zusammen zum Kunden, in diesem Falle ein Tennisverein, der sich entschlossen hat, über das schöne Wochenende für die Mitglieder eine Fahrradtour zum 25-jährigen Vereinsjubiläum zu organisieren. Dazu möchte der Tennisverein beim Fahrradverleih eine größere Anzahl von Fahrrädern leihen. Es stehen aber nicht genügend gut gewartete Fahrräder zur Verfügung. So sitzen der PO und das Teammitglied beim Kunden und überlegen, wie sie das 'Problem des Kunden' lösen können. In dem Zuge kommen sie darauf, dass wenn das Team im nächsten Sprint sich ausschließlich um die Wartung der Fahrräder kümmert, bis zum genannten Termin die gewünschte Anzahl an Fahrrädern zur Verfügung steht.
Wieder zurück beim Fahrradverleih bespricht der PO mit dem Team im Sprintplanning, wie sie den Kundenwunsch (Tennisverein benötigt 25 gut gewartete Fahrräder, um am Wochenende einen Fahrradausflug durchzuführen) genau nachkommen können. Dabei stellt sich heraus, dass man 3 Reifen wechseln müsste und 5 Ketten schmieren müsste. Es stellt sich außerdem heraus, dass dies schwierig im Sprint erreicht werden kann und jemand macht den Vorschlag, man könne vielleicht auf die 2 Tandems zurückgreifen, die bestens gewartet sind. Vielleicht mag im Tennisverein jemand diese besondere Form des Fahrradspaßes? Nach kurzer Rückfrage beim Tennisverein stimmt dieser sofort zu und somit reicht es, nur 2 Fahrräder mit neuen Reifen zu bestücken und bei 4 Fahrrädern die Ketten zu schmieren, was gut in den Sprint passt.
Das neue Sprintziel heißt: 'Ermögliche dem Tennisverein einen Fahrradausflug für 25 Personen bis zum Wochenende'.
Macht das mehr an? Schon eher. Wird sich ein Team mehr anstrengen, dieses Sprintziel zu erreichen? Wahrscheinlicher. Freut sich ein Team darauf, den Tennisverein mit glücklichen Gesichtern auf Tandemfahrrädern davon zu fahren? Auf jeden Fall :)
Wird ein Team, das solche Sprintziele verfolgt erfolgreicher sein als unter den Bedingungen wie eingangs erwähnt? Darauf würde ich persönlich jederzeit wetten!
Also, lasst die Teams an die Kunden ran! Ein Team MUSS verstehen, welche Wirkung eine Anforderung/Sprintziel auf den Kunden hat (bei Erfolg als auch bei Fehlschlag). Daraus entsteht die gewünschte intrinsische Motivation, die SCRUM so erfolgreich macht.
Und um zurück zum Thema zu kommen: Die Eingangsfrage lautete, 'Wie Mut für Innovationen und anspruchsvolle Sprinziele geschaffen werden kann, wo das Umfeld keine Fehlerkultur kennt?'. Hat der Kunde eine Fehlerkultur? Würde er überhaupt eine akzeptieren? Was ist, wenn das Team den Sprint nicht schafft? Würde der Kunde dann sagen: 'Hm, blöd gelaufen, kann halt mal passieren...' Eher nicht. Eine Fehlerkultur zu fordern, die mit einer Relativierung der Kundenwünsche einhergeht, wäre also eher schädlich. Nach innen zu vertreten, dass manchmal Dinge unbeabsichtigt schief gehen und es deshalb wichtig ist, daraus zu lernen, WEIL der eigentliche Kunde eben nicht gewillt ist, Fehlschläge hinzunehmen, ist es etwas ganz anderes. Das macht eine Fehlerkultur (präziser ausgedrückt) zu einer Lernkultur.
Ein Product Owner (für Fahrradverleih) gibt seinem Team folgende Aufgaben mit in den Sprint: Es sollen bei 3 Fahrrädern die Reifen gewechselt und bei weiteren 5 die Ketten gereinigt und geschmiert werden. Was könnte ein Sprintziel sein? Z.B. "Alle Fahrräder sind in gewartetem Zustand".
Ehrlich? Macht mich nicht an, sorry! Ist fade, stupide und solala halt. Wird ein Team alles darum geben, dieses Sprintziel zu erreichen und das Äußerste aus sich herauszuholen? Eher nicht.
Die Frage nach einem anspruchsvollem Sprintziel ist also gar nicht so leicht. Das Problem ist jedoch systemisch bedingt und ein anspruchsvolles Sprintziel kann erst gar nicht entstehen, weil dem Team das eigentliche Kundenproblem nicht bekannt ist.
Das führt uns zur richten Frage: Wie kann das Team besser über das echte 'Problem des Kunden' und nicht das des PO informiert sein? Recht simpel: Indem das Team bereits bei der Anforderungsaufnahme (zumindest in Teilen) dabei ist. Hätte nämlich das Team Zugang zum wirklichen Kunden gehabt, wäre Folgendes passiert:
Ein Teamvertreter geht mit dem PO zusammen zum Kunden, in diesem Falle ein Tennisverein, der sich entschlossen hat, über das schöne Wochenende für die Mitglieder eine Fahrradtour zum 25-jährigen Vereinsjubiläum zu organisieren. Dazu möchte der Tennisverein beim Fahrradverleih eine größere Anzahl von Fahrrädern leihen. Es stehen aber nicht genügend gut gewartete Fahrräder zur Verfügung. So sitzen der PO und das Teammitglied beim Kunden und überlegen, wie sie das 'Problem des Kunden' lösen können. In dem Zuge kommen sie darauf, dass wenn das Team im nächsten Sprint sich ausschließlich um die Wartung der Fahrräder kümmert, bis zum genannten Termin die gewünschte Anzahl an Fahrrädern zur Verfügung steht.
Wieder zurück beim Fahrradverleih bespricht der PO mit dem Team im Sprintplanning, wie sie den Kundenwunsch (Tennisverein benötigt 25 gut gewartete Fahrräder, um am Wochenende einen Fahrradausflug durchzuführen) genau nachkommen können. Dabei stellt sich heraus, dass man 3 Reifen wechseln müsste und 5 Ketten schmieren müsste. Es stellt sich außerdem heraus, dass dies schwierig im Sprint erreicht werden kann und jemand macht den Vorschlag, man könne vielleicht auf die 2 Tandems zurückgreifen, die bestens gewartet sind. Vielleicht mag im Tennisverein jemand diese besondere Form des Fahrradspaßes? Nach kurzer Rückfrage beim Tennisverein stimmt dieser sofort zu und somit reicht es, nur 2 Fahrräder mit neuen Reifen zu bestücken und bei 4 Fahrrädern die Ketten zu schmieren, was gut in den Sprint passt.
Das neue Sprintziel heißt: 'Ermögliche dem Tennisverein einen Fahrradausflug für 25 Personen bis zum Wochenende'.
Macht das mehr an? Schon eher. Wird sich ein Team mehr anstrengen, dieses Sprintziel zu erreichen? Wahrscheinlicher. Freut sich ein Team darauf, den Tennisverein mit glücklichen Gesichtern auf Tandemfahrrädern davon zu fahren? Auf jeden Fall :)
Wird ein Team, das solche Sprintziele verfolgt erfolgreicher sein als unter den Bedingungen wie eingangs erwähnt? Darauf würde ich persönlich jederzeit wetten!
Also, lasst die Teams an die Kunden ran! Ein Team MUSS verstehen, welche Wirkung eine Anforderung/Sprintziel auf den Kunden hat (bei Erfolg als auch bei Fehlschlag). Daraus entsteht die gewünschte intrinsische Motivation, die SCRUM so erfolgreich macht.
Und um zurück zum Thema zu kommen: Die Eingangsfrage lautete, 'Wie Mut für Innovationen und anspruchsvolle Sprinziele geschaffen werden kann, wo das Umfeld keine Fehlerkultur kennt?'. Hat der Kunde eine Fehlerkultur? Würde er überhaupt eine akzeptieren? Was ist, wenn das Team den Sprint nicht schafft? Würde der Kunde dann sagen: 'Hm, blöd gelaufen, kann halt mal passieren...' Eher nicht. Eine Fehlerkultur zu fordern, die mit einer Relativierung der Kundenwünsche einhergeht, wäre also eher schädlich. Nach innen zu vertreten, dass manchmal Dinge unbeabsichtigt schief gehen und es deshalb wichtig ist, daraus zu lernen, WEIL der eigentliche Kunde eben nicht gewillt ist, Fehlschläge hinzunehmen, ist es etwas ganz anderes. Das macht eine Fehlerkultur (präziser ausgedrückt) zu einer Lernkultur.