Nudge am 24.03.2014

Scrum: Meetings

in Projektmanagement | Tags: Agilität, Meetings, Projektmanagement, Scrum

Wie letztens versprochen, geht es weiter in unserer Scrum-Runde mit den im Framework beschriebenen Meetings. Jetzt denkt so mancher bestimmt: “Diese sogenannten Meetings produzieren doch nur Overhead, wir verschwenden jetzt schon viel zu viel Zeit in diesen endlosen, nichtsbringenden Runden!“. Ich kann es ihm nicht verübeln. Doch das Schöne ist:  In Scrum gibt es nur wenige davon, und auch diese sind zeitlich begrenzt und streng fokussiert! Also, lasst uns einen Blick darauf werfen, ich verspreche Euch, es lohnt sich.

Je länger ich mich mit Scrum beschäftige, desto mehr erkenne ich den universellen und minimalistischen Ansatz, den es verfolgt. Und so auch bei den Meetings. Während die Art des Produkts oder Projekts, welches man im Team umsetzen möchte, völlig offen und damit flexibel bleibt, so knallhart verfolgt Scrum doch einige Regeln, wer wann und mit wem welche Aspekte besprechen sollte. Wenn man dieser Regel streng folgt – manche nennen das auch Scrum-by-the-book – kann vieles klarer und effizienter gestalten. Und wer noch im vorsichtigen Stadium der Scrum-Einführung steht, der kann sich sogar auf die wichtigsten zwei konzentrieren. Dazu komme ich weiter unten gleich noch. Zunächst die Übersicht selbst.

Die Meeting-Übersicht für Euch als Download

Wie auch schon im Beitrag über die Rolle des Product Owners, möchte ich Euch auch hier eine ausdruckbare Form im PDF-Format an die Hand geben: Scrum-Meeting-Uebersicht. Mit dieser – natürlich in Farbe ausgedruckt und laminiert – könnt ihr ganz professionell in jedes Meeting hineingehen und für Ordnung und Effizienz sorgen. Eure Mitmenschen werden Euch danken. Wer zu jedem Meeting ein wenig Erklärung in Textform lesen möchte, dem empfehle ich eine einfache Beschreibung à la Wikipedia. Das Thema ist allerdings so religiös, dass es auch ganz dicke Schwarten dazu gibt, in denen quasi auf Knien und mit erhobenen Händen den himmlischen Gaben der Scrum-Meeting-Kultur gehuldigt wird. 🙂

Und diese Ausführungen möchte ich an dieser Stelle auch nicht wiederholen. Mir geht es heute neben dem Download selbst vor allem um zwei zusätzliche Dinge: Erstens möchte ich noch einmal betonen, warum ich die Scrum-Methodik und dessen Meetings für minimalistisch halte. Und zweitens möchte ich – das mögen mir Scrum-by-the-book-Evangelisten bitte verzeihen – die Meetings untereinander priorisieren und Euch einen kleinen Leitfaden an die Hand geben, in welcher Reihenfolge ich die Meetings einführen würde, wenn es wirklich nicht auf einen Schlag machbar ist.

Die Minimalistik der Scrum-Meeting-Kultur

Zunächst wird mir sicher jeder Recht geben, wenn ich behaupte, dass man ohne einen Hauch von Planung wohl kaum etwas in dieser Welt im Team erfolgreich anpacken kann. Und damit wären wir beim Planning Meeting. Ohne das geht es also nicht, und es sollte Teil unseres Meeting-Plans sein. Die Eigenart von Scrum ist nun, dass es davon zwei gibt: Planning Meeting I und Planning Meeting II. What the heck? Ist das doch schon Verschwendung? Nun, der springende Punkt ist, das im Planungsschritt selbst nicht jeden alles interessiert und interessieren muss: Es gibt wie immer eine fachliche und eine technische Ebene. Also kann man diese beiden Meeting auch als zwei Halbzeiten desselben Spiels auffassen. Und die eine Mannschaft spielt nur die erste Halbzeit, die fachliche, mit! Das Team selbst verbleibt zur technischen Planung und stellt sich damit auch ein wenig taktisch für die Umsetzung der fachlichen Anforderungen auf.

Ein drittes Meeting für die erfolgreiche Planung beschäftigt dann mit der Zeitschätzung der Anforderungen. Im Rhythmus von Scrum kommt dieses vor dem eigentlichen Planungsmeeting vor. Jeder wird es kennen, wenn Planungsmeetings dahinschwelgen, weil niemand die richtigen Informationen hat. Mit geschätzten und priorisierten Anforderungen wie in Scrum können Planungen endlich wieder konkret und fokussiert ablaufen: Es geht hier nur darum, die richtigen Anforderungen auszuwählen. Und auch nur einer darf dies federführend tun: Der Product Owner. Na, wenn das nicht zielführend ist!

Und mir wird wohl auch jeder Recht geben, dass es in erfolgreichen Projekten eine gewisse Abstimmung gibt, wer woran gerade arbeitet. In Scrum macht dies das Team selbst. Mit einem täglichen Standup oder Daily Scrum, welches maximal 15 Minuten dauern darf. Geübte Teams liegen zwischen 5 und 10 Minuten. In einer Woche sind das also unter 1h Meeting. Von 40 Wochenstunden ausgegangen, sind das nur 2,5% unserer Arbeitszeit. Und das reicht. Außerdem gibt es diese Stunde nicht am Stück, wo jeder nach 30 Minuten ab oder auf Durchzug schaltet, sondern in verdaulichen Häppchen. Außerdem erlaubt eine tägliche Abstimmung kleine Kurskorrekturen alle 24h. Toll. Nebeneffekt: Das Scrum-Board ist jeden Tag aktuell. Braucht jemand vom Management einen aktuellen Stand, soll er doch ans Board gucken! Keine Zeitverschwendung für Reportings mehr.

Und jeder wird mir vielleicht auch Recht geben, dass man nicht umhin kommt, seine Arbeitsergebnisse irgendwann zu präsentieren. Dies geschieht im Sprint Review. Dieses Meeting kann man, zusammen mit der Retrospektive, auch wieder wie ein Spiel mit zwei Halbzeiten auffassen. In der ersten Halbzeit werden die fachlichen Ergebnisse präsentiert, nach der Pause wertet das Team seine Performance aus und erarbeitet Verbesserungsvorschläge für das nächste Spiel. Dieses letzte Meeting, die Retrospektive, ist vielleicht projekttechnisch nicht wirklich minimalistisch, aber es ist das Meeting, welches Teams Stück für Stück auf eine andere Ebene bringt. Ich würde sogar behaupten, dass die Retrospektive das wichtigste Meeting von allen des Scrum-Frameworks ist. Die Retrospektive macht den Unterschied zwischen Spitzen- und schlechten Teams aus.

Priorisierung und sukzessive Einführung der Scrum-Meetings

Und was, wenn ich das nicht alles sofort umsetzen kann? Nun, ich finde das gar nicht schlimm. Der agile Auftrag sagt: “Inspect and adapt“, oder anders: Der nächste Schritt in die richtige Richtung ist das Allerwichtigste. Am besten, man startet – wenn schon von null an – mit einem kombinierten Review+Planning-Meeting. Trefft Euch einmal pro Woche oder zweimal im Monat, schließt einen Sprint ab und startet einen neuen, beides in einem Rutsch. Von mir aus auch in einem Planning-Meeting auf rein technischer Ebene, sogar mit direkter Schätzung. Wenn ihr weit genug seid, dann ladet den Auftraggeber ein oder ruft ihn an und fangt an, die fachlichen und technischen Planungsaspekte zu trennen.

Was ihr auch ohne Auftrag des Managements tun könnt, ist das Daily Scrum. In der Regel fällt solch ein kurzes Meeting gar keinem auf. Nur, dass halt das Scrumboard dabei entsteht. Und dann steht irgendwann jemand im Büro und fragt “Ach, und du arbeitest gerade daran?“. Mit diesen beiden minimalen Meetings habt ihr es fasst schon geschafft. Ihr seid auf dem Weg zur Agilität (was sowieso eher ein Mindset denn eine Methodik ist).

Danach würde ich daran arbeiten, nach einem großen Abschluss eine Retrospektive zu probieren. Mit den Retrospektiven ist es meiner Meinung nach wie mit der Pareto-Regel: Schon das erste Meeting wird die großen 80%-Probleme ans Tageslicht befördern und ihr werdet, wenn ihr gute Verbesserungen findet, direkt einen echten Qualitätssprung spüren. Schließt Euch dazu aber irgendwo gut ein, wo Euch niemand stören kann. Denn nur in der Offenheit entsteht die Erkenntnis. Schaut dabei auch mal, ob es eine Fehlerursache gibt, die andere Folgefehler verursacht haben ( eine sogenannte “Root-Cause-Analysis“). Für die zeitliche Planung empfehle ich eher weniger als mehr: In der Regel komme ich mit einer Stunde für drei Leute aus, für 5 oder mehr empfehle ich 1,5 Stunden, nicht mehr. Stay focussed.

Wenn ihr das ein paar Mal gemacht habt, könnt ihr darüber nachdenken, die Schätzungen von Euren Planungen zu trennen. Was zunächst nur Eure interne organisatorische Absprache ist, entpuppt sich bei näherem Hinsehen schnell zum ersten Ansatz der Transformation der gesamten Organisation. Denn nun müssen die Anforderungen zyklisch rechtzeitig vorliegen. Wenn sie nicht vollständig oder unverständlich sind, wandert das Ticket postwendend zurück an Eure Auftraggeber. Versehen mit dem Hinweis, dass der nächste Einsendeschluss vor dem nächsten Sprint liegt, um beachtet zu werden. So wird sich Euer Umkreis nach und nach damit zuerst arrangieren und den Zyklus später adaptieren.

Der schwierigste Schritt besteht sicherlich darin, die Organisation zu Plannings, Reviews und deren Spielregeln zu konvertieren. Dafür kann ich Euch keine allgemeingültige Tipps geben, dieser Schritt muss mit viel Selbstbewusstsein und Fingerspitzengefühl angegangen werden. Letztlich bedarf jede agile Organisation auch einer entsprechenden Unterstützung im Management.

So, genug aus dem Nähkästchen geplaudert. Ich wünsche Euch viel Erfolg mit dem PDF-Merkblatt!

 


Das mark ich mir: Alltagz Mr Wong Yigg Del.icio.us Yahoo MyWeb Blinklist Google folkd
 

Leave a Reply

Your email address will not be published. Required fields are marked *