Stefan Liesers Blog

Im Buch The Toyota Way von Jeffrey K. Liker finden sich zahlreiche Perlen, von denen ich hier in loser Folge einige vorstellen möchte. Was mich an diesem Buch am meisten beeindruckt ist die Tatsache, dass sehr viele Ideen der agilen Softwareentwicklung offensichtlich im Toyota Production System (TPS) ihre Wurzeln haben. Einerseits ist es beruhigend, dass die “Erfinder” der agilen Softwareentwickler das Rad nicht neu erfunden haben sondern auf bewährte Prinzipien und Praktiken der “Lean Production” zurückgegriffen haben. Andererseits zeigt mir das Buch, dass wir das Potential von “Lean” derzeit in der Softwareentwicklung bei weitem nicht ausschöpfen. Ideen wie Pull statt Push, One Piece Flow, Kanban und andere bergen viel Potential für die Softwareindustrie. Mehr dazu in späteren Posts.

Beginnen möchte ich mit ein paar Hinweisen für effiziente Meetings. Erst letzte Woche hatte ich wieder mal das zweifelhafte Vergnügen, an einem sogenannten Planning Meeting teilzunehmen. Das Planning Meeting dient in Scrum eigentlich dazu, den nächsten Sprint zu planen. Dazu wird vorher in Estimation Meetings der Aufwand der einzelnen Backlog Items geschätzt. Desweiteren priorisiert der Product Owner die Backlog Items danach, welche Relevanz sie aus Geschäftssicht haben. Im Planning Meeting ist dann das Team gefragt, gemeinsam mit dem Product Owner eine Menge von Items für den nächsten Sprint auszuwählen. Eigentlich ganz einfach.

Doch warum hole ich so weit aus? Eine erste Voraussetzung für ein effizientes Meeting ist ein präzise beschriebenes Ziel. Was soll im Meeting erreicht werden? Was sollen die Ergebnisse des Meetings sein?

Wenn man ein Meeting innerhalb von Scrum “Planning Meeting” nennt, sind damit die Ziele eigentlich definiert. Haben aber, wie in diesem Fall, vorher keine Estimation Meetings stattgefunden, kann das Ziel des Meetings gar nicht erreicht werden. Das liegt schlicht daran, dass das Team die Backlog Items noch gar nicht kennt! Und da ihr Aufwand noch nicht geschätzt ist kann das Meeting nur scheitern. Denn wie sollen Backlog Items zu einem Sprint zusammengefasst werden, wenn ihr Aufwand nicht bekannt ist? Im konkreten Fall wurde einfach im Planning Meeting geschätzt. Ergebnis: schon beim Bearbeiten des ersten Sprint Items zeigte sich, dass die Voraussetzungen für das betroffene Feature nicht gegeben sind. Dies führt zu unnötigen Nachfragen, bremst den Entwickler aus. Statt zu entwickeln muss er Details klären, die eigentlich längst feststehen sollten. Die Root Cause Analysis zeigt hier: der Prozess läuft nicht richtig.

Zweite Voraussetzung für ein effizientes Meeting: die richtigen Leute müssen zusammenkommen. Ein Planning Meeting ohne Product Owner wäre sinnlos. Wenn das Ziel eines Meetings klar umrissen ist, kann man meist auch klar beschreiben, welche Personen am Meeting teilnehmen müssen. Wenn Meetings alle hier aufgeführten Voraussetzungen erfüllen, dürfte es auch kein Problem sein, bei Bedarf Teilnehmer aus dem Management für ein Meeting zu gewinnen.

Dritte Voraussetzung sind vorbereitete Teilnehmer. Jeder Teilnehmer eines Meetings muss wissen worum es geht, muss das Ziel kennen, und muss wissen was seine Rolle im Meeting ist. Dazu muss er sich vorbereiten. Es ist völlig ineffizient, erst während des Meetings die erforderlichen Informationen zu verbreiten.

Als viertes müssen visuelle Werkzeuge genutzt werden. Damit meine ich nicht, dass ein Meeting einen Beamer benötigt. Mag sein dass das manchmal sinnvoll ist. Wichtiger ist aber, dass die Informationen visuell aufbereitet sind. Lange Spiegelstrichlisten oder gar umfangreiche Texte sind völlig fehl am Platz. Die Information muss von allen Teilnehmern schnell erfasst werden können. Die Visualisierung soll dazu dienen, die Diskussion zu ermöglichen bzw. sie zu vereinfachen. In vielen Fällen ist es daher sinnvoller, während des Meetings eine Visualisierung an ein Flip Chart zu zeichnen statt einen Folienfilm abzuspielen. Da die Teilnehmer informiert in das Meeting gehen (siehe nächsten Absatz), dient die Visualisierung in der Diskussion zur Orientierung.

Die fünfte Voraussetzung wird meiner Erfahrung nach am schlimmsten vernachlässigt: Meetings sollen Probleme beheben und nicht Informationen austauschen. Das Austauschen der erforderlichen Informationen muss zwingend vor dem Meeting erfolgen. Nur so ist sichergestellt, dass die Teilnehmer vorbereitet erscheinen können. Wenn die Informationen so komplex sind, dass sie nur schwer in Form einer Email o.ä. übermittelt werden können, mag es sinnvoll sein, vor dem Meeting sozusagen “Auge in Auge” zu informieren. Innerhalb des Meetings sollen die Informationen jedoch allen bekannt sein. Nur so kann effizient an Problemen gearbeitet werden. Und nur so können Meetings zeitlich kurz gehalten werden.

Und eine weitere, die sechste, Voraussetzung: jedes Meeting beginnt und endet exakt wie im Zeitplan vorgesehen. Wenn 10 Teilnehmer 6 Minuten warten müssen, weil sich der Beginn verspätet, kann dies bedeuten, dass eine Stunde Zeit schlicht verplempert wird. Ferner drückt das verspätete Erscheinen zu einem Meeting nicht gerade aus, dass dem Teilnehmer genau dieses Meeting ganz wichtig ist. Das führt oft dazu, dass alle Teilenehmer von vorneherein den Eindruck haben, dass es in dem Meeting um nichts geht. Entsprechend gering ist die Konzentration und die Bereitschaft, etwas beizutragen. In der Folge wird dann auch das geplante Ende des Meetings überschritten.

Die Preisfrage bleibt: was tun? Sollte man eine Einladung zu einem Meeting ablehnen, wenn die obigen Voraussetzungen nicht erfüllt sind? Hm, im Einzelfall mag das jemanden aufrütteln, eine zielführende Strategie scheint mir das alleine aber nicht. Jedenfalls nicht, wenn man diese Reaktion nicht untermauert mit entsprechenden Informationen über die Voraussetzungen für effiziente Meetings. Meist hilft es, wenn ein Team von Entwicklern sich bemüht, die Voraussetzungen einzuhalten, diese kommuniziert und vorbildlich handelt. Andere werden darauf aufmerksam und fragen nach. Es ist ein Lernprozess der länger andauert.

This entry was posted on Monday, August 24th, 2009 at 15:39 and is filed under Clean Code Developer. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.