3 von X

Wie kaum anders zu erwarten beendeten wir den Sprint weit vor der Zeit;

Zum einen konnten die Performer den vom Product Owner (und mir) angenommenen Arbeitsaufwand stark “unterbieten”, zum anderen wurden Arbeitspakete, welche zu diesem Zeitpunk noch nicht relevant waren, oder starke Abhängigkeiten zu nachfolgenden Aktivitäten hatten einfach ‘hinten angestellt’ oder gänzlich verworfen.

Alles in allem machte es dem Team großen Spaß, in dieser Tiefe in die Planung involviert zu sein..

Nun fehlte eigentlich nur noch das ‘Big Picture’, bezüglich dem eigentlichen Ziel unserer Arbeit.

Ich habe bereits angesprochen, dass ein Product Backlog, wie wir es aus der Softwareentwicklung kennen für dieses Projekt wohl nicht besonders viel Sinn machen würde.. aber gänzlich ‘weglassen’ konnten wir dieses Artefakt auf keinen Fall: schließlich hatten wir das hehere Ziel, uns (auch argumentatorisch) gegen Einflüsse von Außen aufzustellen.

Also, bei insgesamt vier Projektaufträgen zum gegenwärtigen Zeitpunkt sollte das PBL wohl Aufgaben aus dem gesamten Programm enthalten; auch mussten wir Linien- und ad hoc Aufwendungen berücksichtigen, um mit der Methode Erfolg zu haben…

Mein Ansatz war ein simpler, der hauptsächlich von gesundem Menschenverstand getrieben wurde:

Wir würden die Vision und das Mission Statement des Auftraggebers sowie die direkten Projektziele zu einem Dokument zusammenfassen, welches dann entsprechend der auftretenden Änderungen iterativ überplant, und dessen Inhalte laufend neu priorisiert werden sollte.

Die Erstellung stellte sich anfänglich etwas kompliziert dar, aber nach dem Wechsel auf eine etwas abstraktere (Meta-)Ebene konnten wir schließlich ein ganz brauchbares PBL erstellen. Auch hier zeigte sich erneut, dass eine entsprechend verständliche Vision und das daraus abgeleitete Mission Statement wahre Wunder im Bezug auf Transparenz und Motivation bewirken können.

Heute geht es mit wehenden Fahnen in Sprint 2.

Die Performer akzeptieren die Methode, trotz Statschwierigkeiten mittlerweile voll umfänglich - nun geht es noch um das notwendige Maß an “Management Attention” - wenn auch noch ‘der Chef’ die Methode und das Vorgehen als wertvoll versteht, sind wir einen großen Schritt weiter - bis dahin kämpfe ich noch mit der “Insellösung” - ich transportiere die Ergebnisse und Abhängigkeiten aus SCRUM in Richtung des großen, tosenden Wasserfalls, gegen den wir anschwimmen..

Unser Fortschritt wird von mir in ein GANTT- Diagramm übersetzt, anhand dessen unser Team die Performance im Gesamtprojekt berichtet.

Wir werden sehen, wo weiteres “Optimierungspotenzial” auftritt, sobald es die ersten Wechselwirkungen zwischen Linie, Gesamtprojekt und unserer kleinen aber feinen SCRUM Gemeinde gibt.

We’ll see..

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…

Diese ist Teil 1 von X in einer Reihe, die wir fortan als eine Art Projekttagebuch hier veröffentlichen werden.

Scrum Master

„Der Scrum Master hat die Aufgabe, die Prozesse der Entwicklung und Planung durchzuführen und die Aufteilung der Rollen und Rechte zu überwachen. Er hält die Transparenz während der gesamten Entwicklung aufrecht, und fördert das Zu-Tage-Treten der bestehenden Verbesserungspotentiale. Er ist keinesfalls für die Kommunikation zwischen Team und Product Owner verantwortlich, da diese direkt miteinander kommunizieren. Er steht dem Team zur Seite, ist aber weder Product Owner noch Teil des Teams. Der Scrum Master sorgt mit allen Mitteln dafür, dass das Team produktiv ist, also die Arbeitsbedingungen stimmen und die Teammitglieder zufrieden sind.“

Quelle: Wikipedia

Ich bin also ein Scrum Master.

Wie konnte das nur passieren? ;c)

Als ich vor etwas über sechs Wochen in meinem aktuellen Projekt als Projektleiter ankam, wusste ich noch wenig über die Vorgänge und Arbeitsweisen, die mich hier erwarten würden.

Die Situation, die ich vorfand lässt sich in etwa so beschreiben:

Es gibt ein motiviertes und kompetentes Team von sechs Performern.

Diese sind innerhalb einer projektgetriebenen Matrixorganisation für den organisatorischen Aufbau einer Supporteinheit zuständig und unterstützen die angrenzenden Bereiche unter anderem durch Reviews ihrer Dokumente auf Berührungspunkte mit dem Betrieb.

Abgesehen davon gibt es derzeit aktuell ein Hauptprojekt und mindestens vier weitere Sekundärprojekte, in welchen die Performer Tätigkeiten übernehmen und welche durch mich gesteuert oder aktuell geplant werden.

Erste Gespräche mit meinem Auftraggeber ergaben, dass es derzeit kaum Transparenz bezüglich Arbeitslast, ad hoc Aufwendungen und zur Erreichung der Ergebnistypen gibt.

Gegen zusätzliche Aufgaben ‚aus der Linie’ (also vom Chef der Abteilung,) deren Projektrelevanz zumindest fragwürdig ist, kann man sich nicht wehren, da aufgrund eben dieser fehlenden Transparenz nicht veranschaulicht werden kann, welche Auswirkungen die Zusatzaufgaben auf die Zeitachse im Projektverlauf haben.

Das Hauptprojekt (Aufbau einer Europaweit einzigartigen Technologie) wird „top-down“ geplant. Es gibt wenig bis gar keine Abstimmung zwischen den ‚Planern’ und den verantwortlichen Projektleitern. Die Projektleiter können zwar Risiken, Probleme und Änderungen an der Zeitachse ‚nach oben’ kommunizieren; jedoch erfolgt hierauf in der Regel verschwindend geringe Resonanz.

Statusberichte werden nur auf Anforderung und bei Bedarf kommuniziert. Die Erstellung dieser Berichte wird als ‚notwendiges Übel’ hingenommen und Teamintern kaum zur eigenen Verortung benutzt. Innerhalb des Teams ist einem einzelnen Performer nicht klar, woran der Kollege gerade Arbeitet. Die Fäden darüber hielt bisher mein Auftraggeber in der Hand – der nun aber zunehmend mit Linientätigkeiten belastet wird und deshalb nicht mehr in der Lage ist das Team zu steuern.

Aufgrund dieser Tatsache wenden die Performer im ständigen Heldeneinsatz eine schwer zu beziffernde Anzahl an Stunden täglich zum Beseitigen von Problemen und dem Beschaffen von Informationen auf.

Ich fasse zusammen:

- Es gibt ein motiviertes Team, dessen Tun ständigen Änderungen (ad hoc vom Chef) unterworfen ist.

- Sowohl Team als auch Projektleitung verfügen nicht über den nötigen ‚Durchblick’ darüber

o ‚Wer’ gerade ‚Was’ zu tun hat.

o Welche Probleme es aktuell bei wem gibt.

o Wann welche Ergebnisse fällig oder fertig sind.

o Welche Abhängigkeiten in den Tätigkeiten der einzelnen Performer bestehen.

Zu diesem Zeitpunk war mir klar, dass eines der Hauptprobleme bei der Steuerung und dem erstellen von Statusberichten nicht etwa schlechte Arbeitsleistung war, sondern vielmehr das Fehlen entsprechend zielgerichteter Kommunikation.

Also habe ich ein Meeting anberaumt, welches Täglich von 13:30 Uhr bis 13:45 Uhr stattfindet. Die Teilnehmer hatten in Vorbereitung zu diesem Termin die in Scrum definierten Fragen vorzubereiten.

“Bist du gestern mit dem fertig geworden, was du dir vorgenommen hast?”

“Welche Aufgaben wirst du bis zum nächsten Meeting bearbeiten?”

“Gibt es ein Problem, das dich blockiert?”

Quelle: Wikipedia

Dieses Meeting war der erste Schritt zu meinem Ziel.

Hinderlich (aus meiner Sicht) war die Tatsache, dass ich die Projektschritte und Arbeitspakete inhaltlich nicht tief genug kannte, um auf die Antworten zu den Fragen entsprechend einzugehen.

Da es ja zu diesem Zeitpunkt noch kein Scrum-Board gab, auf dem wir Arbeitspakete hätten visualisieren können, war die Wahrnehmung der Teilnehmer doch eher abstrakt.

Zu diesem Zeitpunkt jedoch bereits ein erster Benefit:

Die Performer tauschten sich nun täglich nach dem Essen (Bei Kaffee und Süßigkeiten) darüber aus, wer gerade mit was zu kämpfen hat und bis wann welche Ergebnisse zu erwarten wären … und: (eigentlich nicht wirklich im Sinne von Scrum ;c) Ich habe einfach mal fleißig mitgekritzelt und bevor ich mich versah den Statusbericht für die laufende Woche aus den Gesprächen generiert.

to be continued…

(Wer Tippfehler findet, darf sie behalten - mein Lektor hat Urlaub ;c)