Zeit finden, Zeit haben, Zeit nehmen

Zeit finden, Zeit haben, Zeit nehmen

 

In vielen Teams, mit denen ich arbeiten durfte, habe ich oft gehört „Wir haben zu viele Meetings!“

Ich stand dann oft erst einmal sprachlos da und habe mich gefragt, was die wohl meinen können. Ein Daily am Tag und dann alle 2 Wochen einen Sprintwechsel. Ja, die Sprintwechsel sind geballte Events aber sonst?

 

Also begab ich mich auf die Suche… hier ist, was ich gefunden habe: 

1)    Als „zu viele Meetings“ werden auch Termine gesehen, die morgens im Daily ausgemacht wurden, um gemeinsam an Aufgaben zu arbeiten. 

2)    Viele Entwickler sehen Besprechungen, in denen nicht direkt codiert wird als keine Arbeit an. „In der Zeit können wir nichts arbeiten.“ 

3)    Viele Zusatzmeetings aus „der alten Welt“, wie z. B. einzelne Jour Fixe, Statusmeetings, etc. ergänzend zu den Scrum Events.

4)    Viele Zusatzabstimmungen und Vorbereitungsmeetings für Teamworkshops, die man im Team gemeinsam bearbeiten wollte und nur aus Gewohnheit schonmal vorarbeitet. 

 

Das haben wir dann mal transparent gemacht in einer Retro.

 

Wir haben die Events aus Scrum visualisiert mit Ziel und Teilnehmern.

Ausgehend davon haben wir alle anderen Meetings in den Kalendern der Teammitglieder dazugehängt und geschaut, welche davon Sinn machen, welche nicht mehr und wie diese schon in den Scrum Events abgebildet sind.

 

Anschließend haben wir darüber gesprochen, wie sinnvoll die Termine für die Teilnehmer sind und warum Arbeitsmeetings nicht als Arbeit gesehen werden und was man auch an diesen verbessern kann. Oft dauern Meetings auch lang oder man kommt nicht wirklich vorwärts, weil diese auch nicht gut oder gar nicht moderiert sind. 

 

Was führt noch zu zu vielen Meetings?

Manche Teams ziehen sich zu viele Themen in ihren Sprint und empfinden dann auch wenige Regelmeetings als zu viel auch wenn es gar nicht so viele sind. Dies wiederum hat auch verschiedenste Ursachen. 

 

Was könnt ihr damit machen?

Hier könnt ihr ein Experiment machen. Nehmt einen Sprint und nehmt bewusst vom Gefühl deutlich weniger in den Sprint. Ihr könnt euch an der Velocity, wenn ihr die habt, orientieren. Auch wenn sich das wenig anfühlt, versucht es. 

Schaut am Ende des Sprints, wie das war. Wie hat sich das angefühlt? Wie viel habt ihr fertig bekommen? 

 

Was auch hilft, falls ihr das noch nicht macht. Orientiert euch an „stop starting und start finishing“. Das bedeutet, dass ihr nicht alle Themen im Sprint Backlog gleichzeitig und parallel startet, sondern der Prio nach ein Thema nach dem anderen erst fertig macht, bevor ihr die neuen Themen anfangt. 

Warum? Weil ihr dann, wenn ihr merkt, dass ihr die Themen in diesem Sprint nicht mehr schafft oder der große Stress ausarten würde, zu eurem Product Owner gehen könnt und ihm eure Situation transparent machen könnt. Gemeinsam als Team könnt ihr dann darüber sprechen, wie ihr mit dieser Situation umgeht. Nach diesem Prinzip habt ihr dann aber ein paar Product Backlog Items komplett abgeschlossen und nicht alles angefangen. 

 

Mich würde sehr interessieren, wie es euch geht und welche Situationen ihr bei euch vorfindet und wie ihr diesen auch schon begegnet seid?

 

Schreibt mir an stephanie.knoll@emendare.de