Einfach liefern! Agiles Arbeiten aus Sicht eines Teammitglieds.

Scrum verspricht eine schnellere Lieferung und bewirkt dabei langfristig die Entwicklung eines neuen Mindsets in Organisationen. Den Rollen des ScrumMasters sowie des Product Owners widmet sich die Literatur ausgiebig. Wie steht es jedoch um die einzelnen Mitarbeiter im Team/DEV-Team? Wie kommen sie mit ihrer neuen Tätigkeit zurecht? In diesem Erfahrungsbericht möchte ich meine ersten Schritte im agilen Kontext offenlegen.

Die Krux mit dem Liefern

Als ich begann, agil (mit Scrum) zu arbeiten, war ich zunächst überwältigt. Glänzend wirkte diese Art des Arbeitens. Alles schien neu und interessant. Ich wollte jedes Scrum-Meeting-Format kennenlernen, alle Artefakte verstehen und auf jede Eventualität vorbereitet sein, um so schlussendlich als Teammitglied den bestmöglichen Output für mein Unternehmen/Projekt zu erzeugen.Und was muss nicht alles bedacht werden! Der ScrumMaster kümmert sich um den Prozess und die Lieferung, während der Product Owner den Return on Invest im Blick haben sollte. Als Teammitglied scheint es da schon einfacher zu sein. Ich muss lediglich liefern. Doch ist es wirklich so einfach?Die ersten Fragen tauchten auf:

• Arbeite ich denn wirklich nach allen Vorgaben?
• Habe ich alle Regeln beachtet, alles zum Thema gelesen, alle Ideen betrachtet und gewürdigt? Und überhaupt: Wird mein Output denn allen meiner Ambitionen gerecht?
• Erwartet mein Unternehmen vielleicht sogar mehr von mir?

Und ich grübelte weiter: Meine erfahreneren Teamkolleginnen und -kollegen hatten zuletzt beeindruckende Leistungen erbracht. Überhaupt glänzten sie stets mit Expertenwissen. Besser, ich überarbeite nochmal mein Konzept und mache mich erneut schlau, bevor ich am Ende etwas falsch mache oder mich blamiere!Ein neuer Meeting-Termin erschien im Kalender. Kein Problem, dachte ich. Da wir (und ich jetzt auch) agil sind, kann ich den Termin wahrnehmen und mich anschließend schlaumachen. Vielleicht hat ja eine Kollegin, ein Kollege noch eine Idee zu meinem Arbeitsansatz. Meeting erledigt. Jetzt noch ein paar E-Mails und zwei Calls und dann fange ich an. Huch – noch ein Meeting …Man ahnt, wohin die Reise geht. Es gab schier unendlich viele Gründe, mit denen ich rechtfertigen konnte, nicht voranzukommen. Am Ende meiner selbstgesetzten Deadline hatte ich dennoch ein großartiges Konzept. „Daraus könnte etwas werden!“, dachte ich.Was ich nicht hatte, war ein Lieferergebnis. Bei all meinem Interesse und Perfektionismus hatte ich aus den Augen verloren, wovor mich agile Methoden laut meinem damaligen Verständnis eigentlich bewahren hätten sollen.

Was war passiert

Von meiner eigenen Agilität war ich noch meilenweit entfernt. Nein zu sagen, fiel mir schwer. Zu fokussieren noch schwerer. Ich drehte mich im Kreis, ohne es zu bemerken.Ich dachte weiterhin in bekannten Mustern:

• Was passiert, wenn …
• Bloß keine Fehler machen … usw.

Vermutlich bin ich nicht der Einzige, dem es so erging. Ich bin sehr dankbar für den konstruktiven Input eines Kollegen, der meine Arbeitsweise kritisch hinterfragte und mir schnell half, meine Arbeitsweise entsprechend anzupassen. Die Angst davor, etwas falsch zu machen – oder besser – das Streben danach, alles richtigzumachen, führte dazu, dass ich meinem eigentlichen Ziel (der Lieferleistung) aus der Sicht des Kunden (meines Unternehmens) nicht sonderlich näherkam.Ich möchte keinesfalls den Gedanken streuen, dass es nicht wertvoll wäre, sich mit einem Thema auseinanderzusetzen und Probleme vorab durchzudenken. Doch genau hier setzt Scrum an. Durch iteratives Arbeiten, stetiges Feedback und die Wahrung des Prozesses sorgt die Methode dafür, die Fallhöhe bei Misserfolgen massiv zu begrenzen.Am Ende eines 14-tägigen Sprints festzustellen, dass nicht geliefert wurde, ist mit Sicherheit unschön. Ressourcen wurden verschwendet, die vermutlich besser hätten eingesetzt werden können. Verglichen mit einem klassischen Arbeitsmodell, in dem Fehler oftmals erst viel später offengelegt werden, ist das Risiko jedoch verschwindend gering.Nachdem dieses Bewusstsein in meinem Kopf angekommen war, fiel es mir deutlich leichter, mich zu strukturieren und zu liefern – ja sogar Unfertiges mit meinen Kolleginnen und Kollegen zu teilen, dieses transparent zu machen. Ich konnte mich schlussendlich also auf die Arbeit konzentrieren und schnell einen Output erzielen. Das Vertrauen in die Methode half hier sehr. Viele kleine Schritte führten dabei schneller zum Erfolg als ein großer Sprung nach vorne.

Mit Transparenz zum Erfolg

Bis Teams und einzelne Teammitglieder effektiv liefern, kann einige Zeit verstreichen. Liefern Teammitglieder nicht direkt nach der Umstellung wie erhofft, empfehle ich, diese erneut abzuholen. Man sollte den Fehler jedoch nicht in der Lustlosigkeit der Personen suchen.Eine gesunde Einstellung zu Fehlern und zur Entwicklung der Selbstorganisation ist der Weg, den es zu bestreiten gilt. Bestärkend auf die Mitglieder einzugehen und mit ihnen zusammen zu reflektieren, kann hier, wie in meinem Fall, ein wichtiger Schritt in Richtung der Entwicklung des agilen Mindsets sein. Nur wenn dieses Mindset innerhalb des Teams und unter den Mitgliedern wächst, kann Wertschöpfung stattfinden.Was man sich aber immer vor Augen halten sollte: Das Ziel der Arbeit, egal mit welcher agilen Methode gearbeitet wird, ist die Lieferung.