Die simpelsten Weisheiten stimmen immer wieder: Ja, viele Dinge haben zwei Seiten. Schaut man nur auf die eine, hat man das Ganze nicht begriffen. Als ich in meinem vorangegangen Blogartikel darüber schrieb, wie essentiell es für Leader ist, entgegen klassischen Führungsprinzipien loszulassen, Verantwortung ans Team abzugeben – da war dies nur die eine Seite der Geschichte. Die andere lautet: Das agile Team muss lernen, mit der gewonnen Verantwortung unbefangen umzugehen. Das ist gar nicht so einfach, wie man meinen könnte. Als IT-Projektmanagerin der BMW Group kann ich auch hier aus eigener Erfahrung schildern, worauf es dabei ankommt. Das tue ich schon deshalb gerne, weil dabei auch die von mir hochgehaltenen Werte von Working Out Loud wie zum Beispiel das Zulassen anderen Meinungen, das Sichtbarmachen der eigenen Arbeit und das Fokussiertsein wunderbar zutage treten.
Erfolg beruht auf individuellen Freiheiten
Wo beginnt die Verantwortung des agilen Teams? Für mich ganz klar: wenn die Teammitglieder rechtzeitig auf Risiken oder Probleme hinweisen, mit anderen Teams auf Augenhöhe zusammenspielen und gemeinsam Lösungen erarbeiten. Selbstorganisation bedeutet Maximierung der eigenen Kreativität, Mitgestaltung, selbstbestimmtes, selbstbewusstes und auch selbstwertes Arbeiten.
Manche werden sich fragen: Warum sollte ich überhaupt mehr Verantwortung übernehmen als die für meinen klar definierten Aufgabenbereich? Werden nicht Vorgesetzte auch deshalb besser bezahlt, weil sie eben die Last der Verantwortung tragen? Meine Antwort: In agilen Prozessen sind selbstorganisierte Teams erfolgreicher als andere. Sie bringen die Abteilung voran, die gesamte Organisation und damit sich selbst. Außerdem ist Verantwortung beileibe nicht zwangsläufig belastend, sondern kann erfüllend und sinngebend sein. Das schreibe ich nicht mit leichter Hand, das empfinde ich selbst so.
Die Voraussetzungen für Selbstorganisation
Wenn ein Team sich selbst führt, wenn ihm Freiheiten überlassen werden … kann das denn gut gehen? Heute sind Teams bunt gemischt, divers in Alter, Geschlecht und Weltsicht. Damit Selbstorganisation funktioniert, müssen, so paradox es klingen mag, Grenzen und Rahmen gesetzt werden, speziell zu anderen Teams. Der Leader gibt die richtungsweisende Mission vor, es bestehen explizite Regeln oder Entscheidungsrichtlinien. Man kann diese Bedingungen als schützende Begrenzung verstehen, die beiden – Product Owner und Team – Sicherheit geben.
Auf einmal ist also ein Team größtenteils auf sich selbst angewiesen. Ich muss da immer an Bücher wie Jules Vernes „Geheimnisvolle Insel“ oder an Filme wie „Der Flug des Phoenix“ denken. In beiden raufen sich völlig unterschiedliche Spezialisten ihres Fachs zusammen, organisieren sich und überleben auf der abgelegenen Insel bzw. bringen ein Flugzeugwrack mitten in der Wüste zum Starten. Mich beeindruckt, was Menschen, die sich kaum kennen, an schwierigen Situationen meistern. Wie sich eingefleischte Individualisten die Hand reichen. Wie Geistesblitze und clevere Lösungen in der Auseinandersetzung untereinander wie von selbst entstehen. Wie alle gemeinsam auf ein Ziel zusteuern. Solche Abenteuer haben sich auch oft genug in der Realität abgespielt, wenn man nur an frühere Antarktis- oder Himalayaexpeditionen denkt. Beruhigend für mich: Wir selbst sind noch nie in der Sahara abgestürzt und mussten aufkommende Probleme auch nicht mit der Faust regeln. Die Umstände zur Selbstorganisation sind bei BMW selbstverständlich um Welten besser. Aber was unter extremen Bedingungen klappt, wird es erst recht in angenehm temperierten Büroräumen. Mir fällt dazu eine Geschichte aus meinem Arbeitsalltag ein, die noch nicht so lange zurückliegt.
Wenn das Team von sich aus aktiv wird
Montagmorgen haben wir immer unser Daily, ein agiles Meeting, das so um die 15 Minuten dauert. Meine U-Bahn stand mal wieder im Tunnel. Also bin ich fünf Minuten zu spät dran und trete in einen Raum, dessen Atmosphäre so aufgeladen war, dass man damit eine mittelgroße Wohnung mit Strom hätte versorgen können. Das Projektteam besteht aus sechs Leuten. Uwe, ein erfahrener Java-Entwickler, macht gerade seinem Ärger Luft. Er spuckt richtig Feuer!
„Wisst ihr, was das für eine Heidenarbeit ist, so ein Formular mit allen Serveradressen auszufüllen? Und jetzt haben sie es abgelehnt. Einfach so. Warum? Keine Ahnung? Also alles nochmal. Das kostet uns mindestens weitere fünf Tage.“
Ich schalte mich alarmiert ein. „Uwe, geht es um den Serverumzug?“ Fünf Tage Verzögerung würde bedeuten, dass das Team die geplante Verlegung von zehn Servern in ein anderes Rechenzentrum nicht mehr in den drei Wochen schaffen kann, die für diesen Sprint – Zeitraum zum Umsetzen eines Zwischenziels – kalkuliert waren. Damit wäre auch die zeitgerechte Installation eines neuen Releases verzögert, die aufgrund neuer EU-Richtlinien als nächstes eingeplant war.
Uwe nickt grimmig. Und während er aufgebracht seinen Kaffee runterstürzt, verfalle ich in eine überwunden geglaubte Vorgehensweise. Ich biete dem Team nach alter Manier an, selbst das Management der Betriebsabteilung zu informieren, die uns das eingebrockt hat. „Braucht ihr Unterstützung?“ frage ich. Und angesteckt von der schlechten Laune, schiebe ich nach, mich schützend vor das Team stellend: „Von wem kam denn die Ablehnung? Wen muss ich da zusammenfalten?“
Aber so läuft das nicht. Nicht bei einem agilen Team, das gewohnt ist, die Dinge selbst in die Hand zu nehmen. Ich habe Teams erlebt, die sagten einfach nur: „Du, mach mal, das ist nicht unser Business.“ Aber die waren eben auch nicht agil unterwegs.
„Brauchst du nicht, Ilona“, kommt es von Kerstin. Sie hat wieder ihre entspannte Art zurückgefunden, um die sie viele beneiden. „Ich werde mit den Kollegen sprechen, die die Server bereitstellen und denen erklären, worum es uns geht. Wäre doch gelacht!“ Kerstin hatte die User Story für den Test der Server übernommen. Wenn wo etwas hakt, sie findet es raus und löst das Problem.
Uwe hat sich inzwischen eingekriegt. Ich kenne ihn seit langem. Wenn das Gewitter vorbei ist, scheint auch bei ihm schnell wieder die Sonne. Mir fällt es trotzdem schwer, hier nur zuzuschauen. Andererseits: Wie in meinem anderen Beitrag zu diesem Thema geschrieben, muss sich ein Product Owner zurücknehmen können. Außerdem wollte ich noch eine Risikobewertung bis Ende der Woche über die Bühne bringen. Da freue ich mich über jede Aufgabe, die ich nicht zusätzlich erledigen muss.
Cut. Zwei Wochen später, Sprintreview, das abschließende Meeting zu diesem Projekt. Ganz ehrlich? Ich hatte mich wieder auf dicke Luft eingestellt und die eine oder andere Negativnachricht. Doch ich komme aus dem Staunen nicht raus.
Uwe erzählt, wie er sich mit dem Verantwortlichen des Serverteams kurzgeschlossen hatte. „Eigentlich ein feiner Kerl“, resümiert der Java-Spezialist. „Der hat sich doch glatt bei mir für die Ablehnung entschuldigt. Sein Fehler, wie er zugab. Die Server standen übrigens bereit, waren aber für uns nicht sichtbar.“ Und Uwe berichtet, wie er dieses lange Adressformular dann doch schneller als angenommen neu schrieb und dem Serverteam bei der Fehlersuche über die Schulter schaute. Irgendwie sehe ich seinen vergnügten Gesichtszügen eine schelmische Befriedigung an, dass durch sein zupackendes Handeln wieder Schwung in den steckengebliebenen Serverumzug gekommen war.
Derweil gähnt Kerstin wie eine hungrige Löwin. „Na, hast dir gestern Nacht wohl den Star-Trek-Marathon reingezogen“, frozzle ich. Sie ganz aufgeräumt: „Denkste. Ich habe bis lange nach Mitternacht getestet. Wir wollen doch den Termin halten. Und als ich durch war, bin ich total happy ins Bett gefallen.“
Mir bleibt nur noch, alle Akzeptanzkriterien abzuhaken und die User Story anzunehmen. Gut gemacht, Team!
Was ich damit sagen will: Hier hat das Team klar Verantwortung übernommen. Es hätte im alten Trott einfach das Problem melden und auf das Serviceteam warten können. Seine Aufgabe war ja nur, besagtes Formular ordnungsgemäß auszufüllen und am Ende die Server in Empfang zu nehmen und zu testen. Aber die engagierten Mitarbeiter haben von sich aus Verantwortung dafür übernommen, was außerhalb des sprichwörtlichen Tellerrands passiert. Mir hat das außerordentlich imponiert!
Fazit: Selbstorganisation will gelernt sein
Wie Führungskräfte, so müssen auch Teams lernen, mit der ihnen übertragenen Verantwortung umzugehen – sie überhaupt erst einmal anzunehmen. Das geschieht nicht über Nacht. Wenn im agilen Vorgehen viele Leader das Loslassen erst trainieren müssen, gilt dies auch für das Team im Hinblick auf seine Selbstorganisation. Kommunikation ist hier alles. Ich schätze überdies agile Coachs, die bei diesem Prozess begleitend und unterstützend mitwirken. Und natürlich bin ich so von den Qualitäten der Selbstlernmethode Working Out Loud überzeugt, dass ich sie jedem Team auf diesem spannenden Weg nur empfehlen kann.
