Gastautor(en)
Montag, der 20. Oktober 2008

Dr. Scrums Tagebuch #2

2 von X…

Bisher treffen sich unsere Helden einmal täglich um 13:30 Uhr in einem kurzen (15min), knackigen Meeting namens „Boxenstop“.
Der Scrum Master moderiert und nimmt Probleme auf, um deren Beseitigung er sich für das Team kümmert. (nebenbei schreibt er noch immer fleißig mit, damit er seinen Statusbericht voll bekommt *g*)

Zusätzlich dazu gibt es jeden Morgen ein 30 Minuten Meeting zwischen dem Auftraggeber (den wir später noch als Product Owner kennenlernen werden) und mir.

Durch diese Meetings konnte ich Transparenz und Kommunikation erzeugen – und das Vertrauen in mich als ‚Problem-aus-der-Welt-schaffer’ festigen.
Hauptsächlich kümmerte ich mich zu diesem Zeitpunkt wohl um noch nicht beantwortete eMails, ausstehende Termine zur Klärung von diesem und jenem.. Kleinkram eigentlich, der aber bei den Performern Mehraufwendungen erzeugt hat.

In meinen Besprechungen mit dem Auftraggeber habe ich wiederholt interesse an agilmen Projektmanagement erzeugen können – sowie Informationen aus dem Team und die aktuelle Auslastung an Ihn kommuniziert – so dass er besser in der Lage war Zurufe seitens seines Chefs entsprechend fundiert zu würdigen.

Auch kamen wir in diesen Meetings überein, dass wir uns gegen Arbeitslast ‚von Außen’ entsprechend zügig aufstellen müssen – ein Verfahren zur Bewertung und Einplanung der Zurufaktionen musste her. Wir beschlossen, das Team von störenden Einflüssen abzuschotten..

Spätestens jetzt war selbst mir klar, dass es eine Antwort auf unser(e) Problem(e) gibt.
Aber würde ich Scrum (oder auch nur einige Artefakte) in der vorliegenden Situation etablieren können?

– Wir sind umgeben (und als Team Bestandteil) von klassischen PM Methoden… die meisten davon „Top-Down“ von einer Hauptprojektleitung induziert, welche sogar bis auf Vorgangsebene die Planung vorgibt.
– Es gibt einige Artefakte, die in der Softwareentwicklung einen definitiven Zweck erfüllen.. aber wie sieht zum Beispiel das Product Backlog für ein Organisations-Projekt aus?
– Ein Team von sechs Menschen, die in diversen Projekten mitwirken über ein Scrum Board zu steuern (wichtig: sich selbst steuern zu lassen) und dieses Vorgehen auch noch ‚nach Oben’ hin zu rechtfertigen würde.. schwierig sein.
– Scrum hin oder her, es muss eine Brücke geschlagen werden zwischen agilen Methoden und klassischen Status Reports – meine Aufgabenstellung umfasst nicht nur ergebnisorientierte Projektsteuerung, sondern eben auch transparente Status Berichte ’nach Oben‘
– Die Performer haben keine Erfahrung mit Scrum.

Nach meinen Berichten über agiles Projektmanagement und insbesondere Scrum war mein Auftraggeber von dieser Idee überzeugt. Also einigten wir uns auf einen Versuch.

Und wie das Leben so spielt, kam am gleichen Tag ein Sekundärprojekt auf den Plan in welchem wir eine Ausschreibung vorbereiten sollten.

Also kurzum die Planung mit dem Auftraggeber durchgesprochen, Arbeitspakete erstellt und ab zum Schreibwarenladen. Paketpapier, Post-Its, Moderationskarten, Stifte, Posterkleber und Malerkrepp. Eigentlich kann es jetzt losgehen.

Also alle eingeladen zu einem Termin – zwei Bahnen Paketpapier an die Wand geklebt (und das sogar einigermaßen Waagerecht – ich bin ja so stolz!), mit bunten Karten beschriftet und in Spalten abgeteilt.. Fertig war das Scrum Board (welches fortan auf den Fluren vor meinem Büro für einige Verwunderung sorgen sollte – zumindest die war bereits auf meiner Seite)

(Anmerkung: Dem Scrum interessierten Leser ist bereits in meinem letzten Absatz aufgefallen, dass _ich_ die Arbeitspakete aufgeplant habe.. aber dazu gleich mehr.)

Also findet der Termin statt – zwei Stunden Kick Off für das Sekundärprojekt unter meiner Moderation. Mit gleichzeitiger Vorstellung des Scrum-Boards. Und der Methode. In zwei Stunden? Yeah right. Natürlich gab es so viele Fragen zum weiteren Vorgehen, dass wir den Termin glatt um eine Stunde überzogen haben – und selbst im Anschluss daran war der eigentliche Zweck von buntem Papier an der Wand noch nicht wirklich geklärt.

Jeder legt noch schnell ein Ei… erm – oder nimmt sich ein Kärtchen, klebt sein Namenskürzel als Post-It darauf und eigentlich ist ja jetzt alles klar, oder?
Dann sehen wir uns morgen Mittag wieder zum Boxenstop.

Ich rechne es dem Team sehr hoch an, dass sie mich zu diesem Zeitpunkt nicht einfach ‚plattgemacht haben’.. Gründe und Möglichkeiten dafür gäbe es genug.

Am nächsten Tag habe ich herausgefunden was das Problem war.
Die Performer standen bei Kaffee und Schokolade in meinem Büro und konnten mir glaubhaft versichern, dass Sie ja alles mögliche Versucht haben, aber die Aufgabenstellung habe einem kritischen Hinterfragen nicht standgehalten und so wurden die Aufwendungen zumindest dahingehend gering gehalten, dass die Arbeit bis zur weiteren Klärung eingestellt wurde.

Keine User-Story der Welt konnte die Aufgaben so umfassend erklären wie es die Performer untereinander im anschließenden Termin mit wenigen Worten konnten. Zur kurzen Erklärung möchte ich anfügen, dass die User Story im damaligen Fall eher eine Beschreibung des Ergebnistyps war.

Zu meiner Ehrenrettung muss ich sagen, dass ich zu diesem Zeitpunkt eventuell noch nicht einmal daran gedacht hatte, Scrum vollumfänglich einzusetzen – ich wollte lediglich einige Artefakte etablieren, welche die Steuerung leichter machen sollten.

Lessons Learned:
– Die Planung erfolgt im Team. Aus dem Team für das Team. Nur so ist sichergestellt, dass die Arbeitspakete inhaltlich verstanden werden.
– Scrum einzuführen ist entweder ein langsamer, aufbauender Prozess oder
– Ein schneller Prozess mit genügend Zeitinvestment für Vorbereitungen und Erklärungen.
– Kein Scrum Artefakt ist so gut, wie die Summe aus allen – gepaart mit der durchgängigen Anwendung.

Also blieb mir keine andere Wahl.. dem Papier an meiner Wand zufolge würden wir Scrum als Methode einführen. All the way, or no way at all.

To be continued…

Kommentar verfassen

*