Die Weisheit von Scrum

In meinem Berufsalltag arbeite ich nach dem agilen Vorgehensmodell Scrum. Vor dem Wechsel zu meinem aktuellen Arbeitgeber kannte ich agiles Vorgehen nur aus der Literatur oder aus Erzählungen. Zu diesem Zeitpunkt war Scrum für mich eines dieser coolen und neuen Dinge, die man in jungen Firmen macht. Firmen, die ihre IT gerade erst aufbauen und dadurch gleich die neuesten Standards etablieren können. Oder zumindest eine so übersichtliche Größe haben, dass eine Umstellung von klassischen Modellen hin zu agilen, relativ schmerzfrei möglich ist.

Inzwischen habe ich knapp zwei agile Jahre hinter mir und bin der Meinung, dass es nicht nur etwas für die Kleinen ist. Sicher ist es schwieriger agile Vorgehensmodelle in größeren Firmen zu etablieren. Aber das liegt wohl eher an dem Gegenwind, der einem durch Anhänger des Wasserfallmodells entgegenweht.

Scrum verlangt vom Management ein gewisses Maß an Vertrauen in die eigenen Leute. Es ist für sie nicht mehr so einfach alles im Vorraus zu planen und einen einzigen Verantwortlichen für ein Projekt zu bestimmen. Verantwortung müssen in Scrum alle übernehmen, die an dem Projekt beteiligt sind. Man befürchtet vielleicht, dass sich am Ende keiner verantwortlich fühlt und das Projekt kopflos aus dem Ruder läuft.

Ein absolut durchgeplantes Projekt weicht in Scrum bewusst einer teils grob gefassten Anforderungsliste, die Raum für Anpassungen zum Zeitpunkt der Umsetzung lässt. Eine Ausformulierung im Sinne einer Spezifikation findet erst kurz vor der Implementierung statt. Zu den Befürchtungen der Klassik-Fans gehört vielleicht, dass das Produkt zu einer experimentellen Spielwiese der Software-Entwickler wird oder, in Ermangelung einer umfangreichen Spezifikation, an den Wünschen des Kunden vorbei implementiert wird.

Beim Start eines Projekts bestehen in Scrum zwar eine Fülle von Anforderungen, die ebenfalls erfasst und schriftlich fixiert werden müssen, jedoch lange nicht so detailliert wie in einem Pflichtenheft. Wie eine bestimmte Anforderung im Laufe des Projekts genau umgesetzt wird, kann zunächst eine untergeordnete Rolle spielen. Die Implementierungsdetails liegen in der Hand des Teams. Hauptsache ist, die gewünschte Funktionalität ist gegeben. Letztendlich bestimmt der Kunde ob diese auch den Anforderung entspricht. Darum ist es wichtig sich möglichst früh und oft mit dem Kunden zusammen zu setzen und ihm das Produkt zu zeigen. Oft erkennt der Kunde erst dann die Details, die er vergessen hat zu bedenken. Da man beim agilen Vorgehen also nicht blind ein Pflichtenheft herunter programmiert, hat man bei jedem Kontakt mit dem Kunden eine Gelegenheit, das Produkt auf die Wünsche des Kunden abzustimmen.

Aus Erzählungen von Software Entwicklern aus meinem Bekanntenkreis die nach klassischen Modellen arbeiten weiss ich, dass es bei einem sogenannten Request for Change bis zu seiner Umsetzung schon einmal ein halbes Jahr dauern kann. Der Kunde muss also sechs Monate warten bis er seinen Wunsch umgesetzt bekommt. Das ist schon etwas ungünstig, wenn der Kunde die Software bereits produktiv nutzt und erst nach so langer Zeit die Software richtig funktioniert. Sie ist im schlimmsten Fall bis dahin nur eingeschränkt oder gar nicht verwendbar.

Das Vorgehen in Scrum entspricht in interessanter Weise meiner persönlichen Lebenseinstellung. In meinem Leben habe ich meine langfristige Zukunft einige Male geplant. Ich habe mir zum Teil detailliert vorgestellt, wo ich in einigen Jahren stehen werde. Wie sich mein berufliches Leben oder meine Beziehung entwickeln wird. Man macht Pläne, die auf den Schlussfolgerungen anderer Pläne beruhen. Ich habe mich dann so sehr mit der Umsetzung dieser Pläne beschäftigt, dass ich mir nicht mehr so viele Gedanken über Alternativen gemacht habe. Über optionale Lebenswege, die sich unterwegs auftun und vielleicht noch besser für mich gewesen wären. Plötzlich kommt dann irgendetwas anders als es geplant war und das Kartenhaus aus Plänen fällt in sich zusammen.

Meiner Meinung nach birgt Scrum eine grundlegende Lebensweisheit in sich. Menschen sind nicht perfekt. Darum planen sie auch nicht perfekt. Das können sie auch nicht, da kein Plan wirklich alle Variablen der Gleichung erfassen kann. Der Markt kann sich verändern und damit die Anforderungen an ein Produkt. Was heute noch ein offensichtlich wichtiges Feature ist, kann Morgen schon überfüssig wie ein Kropf sein und sollte deshalb auch nicht mehr programmiert werden, nur weil es so im Pflichtenheft steht. Übertragen auf das eigene Leben bedeutet das, man sollte sich ruhig klare Ziele setzen, aber lieber nicht zu detailliert planen. Es sollte Raum für Variation und Spontanität bleiben.

In einem agilen Umfeld zu arbeiten bedeutet für mich also so zu arbeiten, wie ich auch mein Leben leben möchte. Darum empfinde ich ein agiles Arbeitsumfeld wahrscheinlich auch so natürlich und Menschlich. Natürlichkeit und Menschlichkeit ist sicher etwas für Jeden von uns. Nicht nur für die Kleinen.