Ich habe mich in letzter Zeit eingehend mit agiler Software-Entwicklung beschäftigt. Mit jedem neuen Wissens-Baustein ist meine Begeisterung gestiegen. Die Methode hat was, die Methode passt perfekt zu vielen Erkenntnissen aus der Psychologie und Hirnforschung.

Schätzmeeting statt Stress
Stress hat wissenschaftlich gesehen nicht derjenige, der viel arbeitet, sondern derjenige, dem die Selbstbestimmung fehlt. Das ist der Mitarbeiter, dem Aufgaben mit fixen Rahmenbedingungen zugewiesen werden, die er abarbeiten muss ohne sich und sein Wissen gestaltend einbringen zu dürfen. Dass dabei die Gesamtleistung suboptimal bleibt, sollte klar sein.
Das Schätzmeeting in der agilen Software-Entwicklung gibt den Entwicklern Kompetenz und die Möglichkeit, Verantwortung für das Endprodukt zu übernehmen. Es folgt der Regel: “Wer die Arbeit macht, schätzt sie auch!” Der wichtigste Aspekt des Meetings ist die Diskussionüber die jeweilige Aufgabe, Lösungsmöglichkeiten, Ideen oder Stolpersteine. Gemeinsam sind die Entwickler stark und ermitteln auch einen realistischen Wert für den Aufwand – bei einer länger erträglichen Arbeitsgeschwindigkeit und -last.

Ziele motivieren
Wer etwas erreichen möchte, muss wissen, was dieses etwas ist. Er muss sein Ziel kennen und darf es nie aus den Augen verlieren. Dann kann er von der Sogwirkung des Ziels profitieren, Schwierigkeiten auf dem Weg überwinden und schließlich seinen Erfolg feiern. In der agilen Software-Entwicklung erarbeitet der Product Owner eine Vision für das Produkt, ein Teilziel für jeden Sprint und Akzeptanzkriterien für jede Aufgabe. Wo das Team auf seinem Weg zum Ziel steht, ist am Board erkennbar und wird auch in den Daily Stand-Ups sichtbar. Sowohl der Product Owner als auch der Scrum Master sind dafür zuständig, Hindernisse aus dem Weg zu räumen und gute Arbeitsbedingungen für die Entwickler zu schaffen. Und nach der erfolgreichen Zielerreichung? Gemeinsam feiern!

Sinn beflügelt
Natürlich macht die Software-Entwicklung nicht in jeder einzelnen Minute Spaß. Mal ist ein Fehler einfach nicht zu finden, mal schlagen Seiteneffekte zu, mal passiert Unerwartetes. Wenn jedoch der übergreifende Sinn klar ist, wenn der Entwickler weiß, warum er diese Aufgabe lösen muss, wird er auch schwierige Situationen durchstehen. Dadurch, dass die Stakeholder bei jeder Anforderung klar machen müssen, warum diese benötigt wird, entsteht Sinn. Dieser wird dadurch verstärkt, dass der Product Owner mit Weitblick das Ganze sieht und unnötige Aufgaben und Verschwendung verhindert.

Flow durch optimalen Mitarbeitereinsatz
Was ist das, wenn die Mitarbeiter in ihren Aufgaben aufgehen und Höchstleistungen vollbringen? Das ist Flow, wo die Fähigkeiten und die Herausforderung zusammenpassen. In der Agilen Software-Entwicklung zieht sich jeder Entwickler genau die Aufgabe aus dem Product Backlog, die ihm am besten liegt. Zudem wird die gegenseitige Unterstützung groß geschrieben. Die Team-Mitglieder lernen im Pair Programming voneinander oder helfen sich, um offene Aufgaben zügig abzuschließen.

Ein Team aus Musketieren
Die Entwickler sind keine Einzelkämpfer, sondern sie bilden ein Team, das gemeinsam gewinnt oder auch verliert. Egoismen sind fehl am Platz, vielmehr gilt wie bei den Musketieren: “Einer für alle, alle für einen”. Eingespielte Teams sind höchst produktiv, haben Spaß an der Arbeit und schaffen sich oft auch ihre eigene Identität mit Namen und Logo, was die Zusammenarbeit noch weiter verbessert.

 

Und wo ist der Haken?
Den muss es doch geben, denn bei so vielen Vorteilen müsste doch jeder mit fliegenden Fahnen zur agilen Software-Entwicklung wechseln. Einen echten Haken sehe ich nicht, wenn sich neugierige, änderungsbereite Menschen ans Werk machen. Sie werden ihren Weg finden, die Praktiken und Prinzipien an ihre Situation anpassen und mit Leben erfüllen.
Sobald jedoch Machtpositionen, angestammte Rechte und zementierte Vorgehensweisen vorliegen, wird es schwierig. Wenn die Rollen beliebig vermischt und die grundlegenden Prinzipien über Bord geworfen werden, lassen die positiven Effekte auf sich warten. Immerhin herrscht am Ende Einigkeit: Agile Software-Entwicklung – so ein Blödsinn!
Schade, denn ich bin sicher, dass die Grundprinzipien längst nicht nur für die Software-Entwicklung verwendet werden können, sondern auch für interne Dienstleister, die laufend mit neuen Anforderungen konfrontiert werden (z.B. Unternehmensgrafik) oder andere Entwicklungs- oder Wartungsprojekte.