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)
Wird geladen ...
