Hilfe zur Selbstorganisation

Dreh- und Angelpunkte in agilen Modellen zur Softwareentwicklung ist das selbstorganisierende Team. Glaubt man daran, hört es sich wundervoll an: der alte Projekt- oder Teamleiter kann seine Verantwortung zur Organisation von Aufgaben abgeben, denn das Team organisiert sich selbst. Glaubt man nicht daran, macht es Angst, da der alte Projekt- oder Teamleiter Verantwortung abgeben muss an sein Team und das bedeutet Macht- und Kontrollverlust. Und für das Team selbst hört sich das nach unheimlich viel zusätzlicher Arbeit an, denn es muss nun selbst Dinge verantworten und diese Verantwortung ist nicht jedermanns Sache.

Wie kann wer helfen, um eine stärkere Selbstorganisation von Teams zu fördern?

Persönliche Zusammenfassung

• Teams und ihre Mitglieder brauchen Konstanz um Vertrauen aufzubauen
• Teams und ihre Mitglieder brauchen einen freien Raum in dem sie Fehler machen lernen dürfen
• Teams und ihre Mitglieder brauchen einen klaren Rahmen mit verständlich formulierten Regeln, Aufgaben und Grenzen
• Teams und ihre Mitglieder brauchen Unterstützung in dem Prozess
• Teams müssen ihre großen Ziele erreichen und dürfen nicht scheitern

Kurz gesagt

• Selbstorganisierende Teams bedeuten einen Kulturwandel
• Selbstorganisierende Teams entstehen schwer ohne Unterstützung
• Das gesamte Team muss in einem gesteckten Rahmen Erfahrungen machen und die Verhaltensweisen oder Entscheidungen immer wieder überprüfen und anpassen.
• Einfacher wird es, wenn man zu Beginn die Regeln einhält.
• Wichtig ist Zeit für den Aufbau von Vertrauen im Team für eine Kultur, in der alle Beteiligten keine Fehler machen, sondern lernen.
• Das Team muss vor zu großer Demotivation geschützt werden.

Selbstorganisierende Teams organisieren sich nicht selbst

Die Erkenntnis, die ich persönlich nach kurzer Zeit mit Personen und Teams machte, die gerade allgemein mit den agilen Methoden oder mit Scrum im Speziellen starteten, war und ist immer noch und immer wieder ernüchternd: Selbstorganisierende Teams organisieren sich nicht selbst. Zu eingefahren sind alte Rollenbilder bei allen Beteiligten vom Team-Mitglied über Projektleiter und Management bis hin zum Kunden. Was aber kann man tun? Muss am Ende doch ein Projekt-Leiter das Projekt leiten oder ein Manager das Team managen?

 

Erfahren, überprüfen, anpassen im Rahmen

Hier steckt eine große Herausforderung für den Prozessverantwortlichen (bei Scrum der Scrummaster), dessen Aufgabe es ist, für die Einhaltung der gemeinsam vereinbarten Spielregeln und Prozesse zu sorgen und ein gemeinsames „Überprüfen und Anpassen“ zu etablieren. Er hilft dem Team auf dem Weg zur Selbstorganisation. Das Team muss dabei die Möglichkeit haben, eigene Erfahrungen zu machen. Nur wer selbst erlebt, was die Verantwortung zur Selbstorganisation bedeutet, wird verstehen, um was es eigentlich geht. Wichtig ist für diesen – wie für jeden anderen Lernprozess auch – ein fest gesteckter Rahmen, der zunächst im Team erarbeitet (oder bei weniger eigenständigen Teams vom Prozessverantwortlichen vorgegeben) wird. Der Prozessverantwortliche achtet darauf, dass sich das Team innerhalb des Rahmens mit seinen Grenzen und Aufgaben bewegt. Für den Prozess des Erfahrens und der anschließenden Überprüfung und Anpassung von Verhaltensweisen oder Entscheidungen braucht ein Team eine Konstanz und Zeit zur Entwicklung und Entfaltung.

Einhaltung der Spielregeln

Man sollte meinen, dass sich Software-Kanban besser eignet zum Lernen der Selbstorganisation als Scrum, da sich die Prozesse im Software-Kanban an den Arbeitsprozessen des jeweiligen Teams orientiert. Es ist aber tatsächlich genau umgekehrt. Scrum ist der bessere Prozess hierfür, da es wenige aber dennoch klar definierte und für jeden leicht verständliche Regeln gibt. Es handelt sich dabei um Regeln, die ein selbstorganisiertes Team fordern und so bei Einhaltung der Vorgaben die Notwendigkeit und auch die daraus resultierenden Verhaltensweisen erlebbar machen. So empfiehlt es sich nicht nur, agiles Denken und Selbstorganisation im Rahmen von Scrum zu lernen. Besonders gut können die Teammitglieder (inklusive des Product Owners) dann lernen, wenn der Scrummaster gerade zu Beginn sehr diszipliniert auch gegen eventuelle Hürden auf die Einhaltung des Prozesses nach „dem Lehrbuch“ achtet. Manche Ideen und Gründe dahinter werden dabei vielleicht nicht gleich allen verständlich sein, das Verständnis wird aber mit mehr Scrum-Erfahrung mehr und mehr kommen.

 

Wir machen keine Fehler, wir lernen

Nachdem anhand dieser bestehenden Regeln jedes Teammitglied die sowohl positiven wie negativen Erfahrungen mit dem Erreichen oder Nichterreichen der Aufgaben und Ziele aus diesem Regelwerk gemacht hat, ist man dem selbstorganisierenden Team ein gutes Stück näher. Dabei gilt es auch eine Kultur des „Fehler-machen-dürfens“ zu etablieren und deutlich zu machen, dass es oft gerade die “Fehler” sind (also das Nichterreichen von Zielen oder die Nichteinhaltung von Regeln mit daraus resultierenden Konsequenzen), die einen näher zum Ziel bringen, sofern man sich damit auseinandersetzt und daraus lernt. Es ist wichtig zu verstehen, dass Einzelpersonen oder ganze Teams keine Fehler machen, sondern lernen. Auch das erfordert eine gewisse gemeinsame Zeit für den Aufbau von Vertrauen innerhalb des Teams.

 

Was tun, damit es läuft?

Eine wichtige Aufgabe des Scrummasters ist es, auf die Einhaltung des Prozesses zu achten und dabei auch Hindernisse aus dem Weg zu räumen. Genauso wichtig ist gerade bei unerfahreneren Teams das Coaching. Was aber kann der Scrummaster tun, wenn er dem Team die Chance geben soll, eigene Erfahrungen zu sammeln? Er kann das Team mit den richtigen Fragen fordern oder gar provozieren, er kann Anregungen geben, Vorschläge machen, Gespräche und Diskussionen anregen und auch moderieren und er sollte im Interesse des Product Owners und vor allem im Interesse des Teams vor allem alles dafür tun, dass das eigentliche Ziel eines Sprints erreicht wird, denn es gibt wahrscheinlich kaum etwas Demotivierenderes, als das Nichterreichen eines Ziels trotz starker Bemühungen. Ein Sportler in seinem Kajak, der versucht in wildem Gewässer gegen den Strom vorwärts zu kommen und sich nicht vom Fleck bewegt, der wird irgendwann aufgeben und dabei Gefahr laufen, in den Wellen unterzugehen. Neben all den eigenen Erfahrungen ist es also überaus wichtig, dass die Teams vorankommen und nicht versagen, dass die Teams nicht das von ihnen zugesagte Ergebnis nicht liefern können. Bevor das passiert, kann und sollte auch ein Scrummaster – nicht der Product Owner – Entscheidungen für das Team treffen. Denn eines darf niemand vergessen: Das Team lernt noch und beim Lernen ist durchaus Unterstützung gefragt.

Vergleichen kann man das gut mit einem Kind, das Fahrradfahren lernen will. Es wird sich kaum mehrmals auf das Rad setzen, wenn es immer alleine losfahren muss und immer wieder schmerzhafte Unfälle hat. Motivierender ist es, wenn das Kind zu Beginn öfter und nach und nach immer weniger aufgefangen oder gehalten wird, bis es alleine fahren kann. Und auch ein erfahrener Radfahrer kann immer wieder stürzen oder in Unfällen verwickelt sein, das Vertrauen in die eigene Fähigkeit Fahrrad zu fahren wird dadurch dann aber kaum beeinflusst. Grundvoraussetzung für all das ist die eigene Bereitschaft, lernen zu wollen.