Frage der Woche: Eigeninitiative im Team

Hallo liebe Community,

es ist wieder Montag und wir starten die Woche mit einer neuen Frage.
Diesmal geht es um Eigeninitiative.

Wie erreicht ihr mehr Eigeninitiative in eurem Team?

Was sind hier deine Erfahrungen oder Tipps?

Ich freue mich auf einen spannenden Austausch mit euch.

Liebe Grüße, Dani

Klare Ziele in Workshops mit den Teams, klare Verantwortlichkeiten bei Resultaten und Tasks und dann einfach mal ne Woch loslassen und sehen obs läuft oder nicht (aber natürlich gerne für Fragen und Coaching bereit sein)

1 Like

Ich versuche dies meist mit den folgenden Punkten:

  • Kurzfristige, definierte Ziele, die gemeinsam bestimmt werden (wie auch von Carsten angesprochen).
  • Eigeninitiative nicht pushen, sondern erlauben (Nicht jeder fühlt sich gleich wohl, wenn plötzlich gesagt wird, dass sich was ändert)
  • Delegation Poker & Board :wink:
  • Follow Through - Wenn zusammen das Ziel gesetzt wurde, wo eigeninitiativ entschieden wurde, dann sich da raushalten (auch wenn es heisst, dass man in einem Projekt eventuell scheitert). Deshalb auch wichtig, der nächste Punkt:
  • Safe-To-Fail Environment - dem Team keine grossen Projekte aufbinden und sie dabei allein lassen, wenn ein Scheitern die Zukunft der Firma bedroht.
  • Self-Fulfilling Prophecy beachten: Arbeiten nicht immer verbessern, auch wenn es ein kleines Scheitern bedeutet, sondern auch Fehler bewusst zu lassen. Wenn wir dauernd verbessern, was unser Team liefert, dann geben die sich am Ende keine Mühe mehr (ist mir schon passiert).
3 Likes

Kannst du das bitte genauer erläutern? Ich verstehe nicht, warum ein Team sich keine Mühe mehr geben sollte.

1 Like

Die Frage ist, wie sich fehlende Eigeninitiative äußert? Wohl am ehesten dadurch, dass das Team immer wieder Führung einfordert und andauernd Fragen stellt, was als nächstes zu tun ist, wie etwas zu tun ist, wer was machen soll. Da halte ich es ähnlich wie bei meinem Sohn: ich frage dann gezielt, was sie davon selbst beantworten können, bzw. warum sie etwas nicht auch selbst beantworten können? Das zwingt die Kollegen und Kolleginnen dann aus der Komfortzone.

2 Likes

Ja, das war eventuell ein wenig kurz formuliert. Aber in Retrospektive ist es mir passiert: Ich hatte in meinem ersten Job immer wieder Dokumente für meinen Chef vorbereitet. Das waren Newsletter, Verträge, Präsentationen, etc. Und egal, wie viel Mühe ich mir gab, es kam immer ein komplett rotes Dokument mit Verbesserungen, aber nicht viel Erklärungen zurück.
Ich begann dann pro Dokument weniger Zeit zu investieren - warum auch, wenn es eh nie gut genug war.

Das äusserte sich dann so, dass meine Ergebnisse nicht besser wurden, nach dem mein Chef die Firma verliess und ich seine Rolle übernahm - nur dass dann das Ergebnis direkt Kunden lesen konnten.

Ich denke, wenn mein Chef damals mir eher die Verantwortung und das Outcome kommuniziert hätte, anstatt an Formulierungen rumzudoktern, hätte es mir eventuell besser geholfen.

(Der Chef war aber gut, ich habe viel gelernt und setze auch noch viel davon in meinem heutigen Umfeld ein)

1 Like

Danke Chris, das erklärt mir das vorherige Statement und ich kann es nun auf ein Team bezogen verstehen.
Würdest du die Self-Fulfilling Prophecy auch bei regelmäßigen Anpassungen bezüglich der Capacity und Velocity sehen? Ich frage deshalb, weil mein Scrum Team sich seit einiger Zeit permanent übernimmt und die Sprintziele nicht erfüllt. Und ich meine nicht, dass nur 1 Story nicht fertig wird, sondern nur roundabout 50%. Und alle Maßnahmen, die wir in der Retro besprechen, greifen nicht. Die Stakeholder sind unzufrieden. Könnte als mein immer wiederkehrendes Finger in die Wunde legen dazu führen, dass das Team sich nicht mehr Mühe gibt an dem Zustand etwas zu ändern?

1 Like

Ich sehe nur genau zwei Maßnahmen, die zu tun sind, ohne Euren Kontext zu kennen:

  1. Reduktion der Menge an Stories/Tickets um mindestens 50% für die nächste Iteration.
  2. Mehr Story-Slicing, bessere Besprechung der einzelnen Aufgaben, bessere DoR usw.

Wer (Stakeholder, PO, du als SM, Rest des Teams) reagiert wie auf diesen Vorschlag?

IMHO haben mindestens PO und SM die Aufgabe, hier auch gegenzusteuern und die obigen Maßnahmen festzulegen AKA durchzusetzen, wenn der Erkenntnisknoten nicht greift.

1 Like

Ich halte es mit Daniel Pink: Autonomie, Mastery und Purpose und das in einem ehrlichen funktionieren Team in einer fordernden aber safe-to-fail Umgebung. Ich halte “erlernte Hilflosigkeit” wie Ihr es andeutet auch für einen der größten Blocker.
Eine weitere Schwierigkeit ist, dass es bestimmt auch immer wieder Kollegen geben wird, die weniger Einsatz zur Eigeninitiative zeigen als extrovertierte Front-PerformerInnen. Mich würde interessieren, wie Ihr das coachen würden und außerdem erlernte Hilflosigkeit vermeidet?

3 Likes

Ich kenne deinen konkreten Kontext gerade nicht, Björn L., mein erster Impuls war gerade, zu prüfen welche Form von Führung & Begleitung die einzelnen Personen in dem Team benötigen. Damit hätte ich einen Anhaltspunkt, wie ich mit der Person umgehen, sie führen und unterstützen kann, um mehr in Richtung Eigeninitiative zu kommen. Sprich: Tendenz zum Einzel-Coaching der Personen, um maßgeschneidert das zu liefern aus Führungs- und Coaching-Sicht, was die Person benötigt. Alte Haltungen und Glaubenssätze beleuchten und gemeinsam einen Plan machen, was nächste Schritte sein können.

Es kann ja z.B. sein, dass sich eine Person, die wenig Eigeninitiative zeigt, sich von anderen, du sprachst von “extrovertierten Front-PerformerInnen”, überfahren oder verdrängt fühlt. Da gäbe es zig Möglichkeiten, was da hinter stecken kann. Dem würde ich gemeinsam mit der betroffenen Person auf den Grund gehen und damit arbeiten.

In der Vergangenheit hatte ich Personen im Team, die sehr negative Erfahrungen gemacht hatten, wenn sie ihre Meinung geäußert hatten und maximal frustriert waren dadurch. Das hat ne ganze Weile gedauert, bis wir das auflösen konnten und die Personen wieder mehr in ihr Selbstvertrauen gekommen sind und auch die Haltung ablegen konnten von “wenn ich jetzt was sage, wird das eh wieder nicht gesehen oder ist falsch.”

Auch wenn Menschen aus einem alten Job negativen Bias mitbringen, kann das viel im neuen Team kaputt machen. Das hatte ich auch schon… da war erstmal angesagt, die Person ins “hier und jetzt” zu holen und den Unterschied zum alten und neuen Job mehr präsent zu machen, damit die Projektionen aufhören.

In Summe: passendes Coaching für jede Person plus die dazu passende Führung auf den nächsten Schritten, um das neue Verhalten zu etablieren.

Hilft das vielleicht als Impuls?

Viele Grüße, Dani

Das ist schwierig zu beantworten, ohne den Kontext des Teams zu kennen.

Es gibt hier viele verschiedene Möglichkeiten, warum das der Fall ein kann:

  • Eventuell Self-Fulfilling Prophecy, wie oben beschrieben. Das würde sich aber eher individuell niederschlagen, nicht vom Team gesamt (oder es ist eine sehr dysfunktionale Zusammenarbeit: Wir gegen die). Es ist eventuell etwas mehr Systemisches.

  • Zu viele Sprintziele (zum Beispiel durch den Versuch, den Sprint Backlog im Nachhinein zu Sprintzielen zu pushen.), was bedeutet, dass Leute individuell sich zu Stories / Tasks hingezogen führen, nicht zum Inkrement. Das kann zu isolierter Arbeitsweise und dadurch dann kaum Kollaboration; jeder ist beschäftigt mit “seinem Task” (wenn dann noch individuelle Leistung oder Velocity gemessen wird, führt das nur zu “Task-Pushing”, nicht zu Produktentwicklung).
    Das sollte im Daily Scrum sichtbar sein, wie zusammengearbeitet wird. Wenn es das nicht gibt oder da da keine Impediments aufkommen, dann ist es schwer dagegen zu steuern. Deshalb, mein Vorschlag: nur ein Sprintziel als Outcome, die Stories sind dann die Konsequenz des Ziels.

  • Zu große Stories - wie bereits von Björn angesprochen. Können die besser gesliced werden?

  • Zu viel Einfluss von außen, etwa Stakeholders. Ein großes Problem in Agile/Scrum sehe ich immer wieder, dass der PO mehr bei den Stakeholdern sitzt als beim Team. Dadurch wird er eigentlich ein Proxy und trifft nicht die Entscheidungen, sondern kommuniziert die nur. Das Team wird zum Outsourcing-Partner des Business. Wenn man Scrum ganz radikal anschaut, sollte das Team entscheiden, WAS gebaut wird. Der PO muss erklären können, WARUM was wichtig ist. Das bedeutet PO und Team müssen zusammen in Team sitzen.

Da gibt es sicherlich noch mehr, aber mehr fällt mir im Moment nicht ein.

1 Like

Hi Zusammen, nicht so einfach zu beantworten, weil der Kontext immer unterschiedlich ist.

Meiner Erfahrung nach sind 2 Dinge elementar:

  • Gibt es ein „Team Agreement“ (Art der Zusammenarbeit, Klarheit, Sinn des Handels, Impact der Arbeit etc.
  • wie ist um die psychologische Sicherheit bestellt

An den beiden Themen würde ich zunächst arbeiten und ohne Team Agreement gar nicht anfangen. Bitte nicht den Standard verwenden, sondern mit dem Team zusammen entwickeln, transparent machen und regelmäßig checken.

Vielleicht ist das Thema fehlende Eigeninitiave nur ein Gefühl des Gegenüber, aber für einen selbst völlig ok. Da hilft nur Reden.

Danke für deine Impulse, die werde ich mir genauer durch den Kopf gehen lassen und prüfen, ob dies auf mein Team zutrifft.

Punkt 1 habe ich jetzt im Planning gemacht und dem Team eine harte Grenze vorgegeben, PO ist auf meiner Seite und befürwortete das vorgehen, das Team äußerte Unmut darüber, aber ich konnte sie a) mit nackten Zahlen der vergangenen Sprints überzeugen weniger zu ziehen und b) habe es als Experiment deklariert (was habt ihr zu verlieren, wenn ihr es ausprobiert?). Ich bin gespannt :star_struck:

2 Likes

Ja cool!! Glückwunsch! Magst du den Ausgang eures Experiments dann vielleicht auch noch mit uns teilen?

Ich möchte ein wenig über den Ausgang des Experiments berichten.
Das Experiment ist übergegangen in Alltag. Der erste Sprint nachdem ich eine harte Grenze vorgegeben hatte, war super. 90% Reliability. Team happy, Stakeholder happy, Scrum Master reibt sich freudig die Hände :grinning:
Im darauffolgenden Planning war das Team defensiver bezüglicher ihrer Planung und Schätzung, dennoch musste ich wieder bremsen und ein Limit setzen - wieder gab es Unmut. Am Ende dieses Sprints haben wir wegen Krankheit nur 60% geschafft, somit nicht ganz so viel Freude aller Beteiligten.
Im nächsten Planning ging es ähnlich allerdings hatte ich Urlaub und konnte somit nicht “gegensteuern” dementsprechend war das Ergebnis.
Kurz, das Team hat verstanden, dass sinnvolles Story-Slicing und Planen mit Puffern sinnvoll ist. Leider sind sie nicht mutig genug wirklich 50% weniger als vor einigen Monaten zu ziehen, sondern reduzieren immer weniger. Mal klappt es, mal nicht, aber in Summe wird es besser.
Daher danke für eure Impulse! :heart:

wie schön! Mein Impuls ist: weiter dran bleiben - und wäre es eine Idee, dir das Thema “Mutig sein” mit deinem Team zu schnappen? Da steckt der Hebel drin. Du könntest der Frage nachgehen (mit dem Team gemeinsam), was sie davon abhält, den Scrum-Wert “Mut” mehr zu leben. Was brauchen sie von dir oder von anderen, um das zu tun? Und wie ist grundsätzliche ihre Interpretation von Mut. Als Retro-Idee.

Viele Grüße!

1 Like

Danke, ähnliche Gedanken hatte ich auch schon. Ich werde da weiter dran bleiben und mit dem Team am “Mutigsein” arbeiten.