Auf ins Getümmel

"Projektmanagement läuft in die falsche Richtung. Es ist an der Zeit, etwas ganz anderes zu machen und das Team in den Mittelpunkt zu stellen. Weg von der Verwaltung der Ressourcen, hin zum Team, das allein klarkommen muss!" So umreißt Boris Gloger den Grundgedanken von Scrum. Im Interview erläutert er, wie die Rebellenbewegung aus der Softwareentwicklung zur Herausforderung für Befehls- und Kontrollorganisationen wurde.
Boris Gloger zählt zu den Pionieren und Innovatoren von Scrum weltweit. Er war der erste Certified Scrum Trainer und wurde von Scrum-Erfinder Ken Schwaber ausgebildet.
 

Herr Gloger, Rugby als Metapher für Teamarbeit - das klingt martialisch. Ist das wirklich eine gute Idee? 

Die Metapher stammt von Ikujiro Nonaka und Hirotaka Takeuchi, zwei Wissensmanagementgurus aus Japan, die sich 1986 schon gegen das starre Lehrbuchmodell der Produktentwicklung wandten, wonach man zunächst analysiert und dann brav Phase für Phase abarbeitet. Sie forderten, Produktentwicklung solle funktionieren wie in einem Rugbyspiel, wo alle Mitglieder eines Teams gleichzeitig zur Ziellinie laufen. Und sie haben gesagt, lasst uns doch diese Methode nach einem Begriff aus dem Rugby einfach "Scrum" nennen. Da kommt die Idee her.
 

Scrum heißt? 

Bei einer Freistoß-Situation im Rugby bilden die Spieler einen Kreis. Dieser Kreis der Spieler wird "Scrum" genannt. Die Metapher ist, dass die Leute miteinander und gemeinsam um den Ball im Rugby beziehungsweise im Team um die Entwicklung eines Produktes ringen. Da ist nicht einer, der ansagt, und es ist keiner draußen. Sondern alle sind im Team und arbeiten miteinander.
 

Wörtlich übersetzt heißt Scrum ja Gedränge. Wie wörtlich darf man das nehmen? 

Nehmen wir ein simples Beispiel: Stellen Sie sich vor, Sie geben eine Party. Sie haben Leute eingeladen, aber sind nicht rechtzeitig fertig geworden. Es ist noch nicht gekocht, es ist noch nicht gedeckt, aber die Gäste kommen schon. Alle wissen: Wenn wir einen schönen Abend miteinander verleben wollen, muss jeder anpacken und was tun. Wir beschließen, wer was macht und wie alle miteinander arbeiten. Es geht um die Zusammenarbeit, nicht darum, dass einer plant. Insofern herrscht Gedränge in der Küche.
Alistair Cockburn, ein frühes Mitglied der Scrum-Bewegung, hat eine wunderschöne Metapher geprägt: Er sagt, Menschen sind wahnsinnig gut im Herumschauen: Jeder schaut und guckt, wo er sich einbringen kann. Eine Gruppe von Menschen, die in einem kurzen Zeitabschnitt möglichst eng zusammenarbeitet, bekommt etwas auf die Reihe, wenn man sie nur in Ruhe lässt.
 

Wie hat sich die Methode entwickelt - und für was ist sie gut? 

Man sagt, Scrum sei eine Projektmanagementmethode. Eigentlich aber geht es um Produktentwicklung: um eine Methode, wie man systematisch Stück für Stück ein Produkt erzeugen kann. Dazu braucht es immer alle Wissenden, also alle Leute, die beteiligt sein sollten. Alle diejenigen müssen sich zu einem Team formieren, die notwendig sind, um das Produkt zu erzeugen.
Jeff Sutherland und Ken Schwaber haben das 1994/95 miteinander entwickelt und ausprobiert. Ihr Ziel war damals, ihre Softwareentwicklungsprojekte besser zu strukturieren - mit klaren Aufgaben und mit kleinen Teams, die möglichst selbstorganisiert arbeiten können, also ohne große Managementbeteiligung. 2001 gab es das erste Buch Agile Software Development with Scrum, also agile Softwareentwicklung mit Scrum.
Kurz darauf zeigte sich, dass man mit Scrum nicht nur Softwareentwicklungsprojekte, sondern auch andere Projekte organisieren kann. Scrum erklärt ja nicht, wie man Software entwickelt, sondern ist ein Prozess, der dafür sorgt, dass ein Projekt vernünftig funktioniert. Das nächste Buch hieß dann Agile Project Management with Scrum. Zwischen 2003 und 2007 wurde immer klarer, dass man mit Scrum gar nicht so sehr ein Projekt managt, sondern das Liefern von Teilen von Produkten. So entsteht inkrementell, also Stück für Stück, immer mehr von diesem Produkt. Es handelt sich auch nicht um ein Projekt, weil das immer einen klaren Anfang und ein klares Ende hat.
Scrum zielt also auf Produktentwicklung. Und viele Firmen merken, dass es ihnen genau daran mangelt. Sie wissen einfach nicht, welches Produkt sie haben wollen. Darüber wurde aber nie geredet. Denn man hat gesagt: "Wir müssen ein Projekt machen!" Nicht: "Wie sieht das Produkt aus?"
 

Und was ist ein Sprint? Eine Methode innerhalb von Scrum? 

Nein, der Sprint ist das Zeitintervall zwischen dem Moment, zu dem entschieden ist, welches Produkt wir liefern wollen, und dem Moment, in dem wir mit der Lieferung fertig sind. Die Metapher kommt wieder aus dem Rugby: Einer hat den Ball in der Hand und alle sprinten gleichzeitig in Richtung Ziellinie. Die Ziellinie steht für das Ende des Zeitintervalls, das wir uns vorgenommen haben. Der erste Sprint bei unserer Party ist, dass wir alle miteinander am Tisch sitzen und jeder etwas zu essen hat.
 

Bleiben wir bei dem Bild: Alle rennen los. Wie geht’s dann weiter? 

Sagen wir, das Team trifft sich an einem Dienstagvormittag; der Product Owner hat eine Liste von Features mitgebracht, die er realisiert haben möchte. Die Leute im Team versuchen nun, genau zu verstehen, was diese Liste bedeutet und was da im Detail entwickelt werden soll. Sie entscheiden miteinander, was sie glauben, in zwei Wochen liefern zu können, und was sie liefern wollen. Die Frage dabei ist: Was wollen wir als Team liefern? Das impliziert: Dazu können wir dann auch stehen, weil wir ja freiwillig gesagt haben, dass wir das liefern möchten.
Wenn das passiert ist, überlegen sie gemeinsam: Was müssen wir genau tun? Wie wollen wir die einzelnen Dinge umsetzen? Wer kann was tun? Am nächsten Morgen setzt man sich dann in einem "Daily Scrum" zusammen. Man versammelt sich vor dem sogenannten Task Board, auf dem visualisiert ist, wer gerade was tut. Das passiert jeden Tag. Nach dem Daily Scrum arbeitet dann jeder an der Sache, die er sich vorgenommen hat; am nächsten Morgen redet man im Team miteinander, wer was geschafft hat.
So arbeiten wir uns Schritt für Schritt voran - und erzeugen hoffentlich alle zwei, drei Tage ein Stückchen fertiges Produkt, das der Product Owner anschauen kann. So geht es meist zwei Wochen, manchmal auch vier; und am Ende dieses Intervalls überlegt man miteinander im Team und gemeinsam mit Usern und Product Owner, was man an dem Produkt noch verbessern könnte. Dann wird entschieden, was im nächsten Intervall gemacht oder auch nicht gemacht wird.
Man geht quasi - wie im Rugby - zurück in die Kabine und diskutiert miteinander, ob das Spiel gut gelaufen ist. Was hätten wir verbessern können? Wie hätten wir uns besser miteinander abstimmen können? Welche Probleme hatten wir, die wir das nächste Mal nicht wieder haben wollen? Und so weiter.
 

Es gibt also ein Miteinander, keinen klassischen Projektleiter? 

Exakt. Die Kunst eines sogenannten Scrum Masters ist es, dieses Miteinander zu schaffen. Er ist derjenige, der das Team coacht. Der sieht, da ist eine Lücke, da muss man noch mal hinschauen, da ist ein Defizit oder eine Störung. Aber eben nicht in dem Sinne eines Projektleiters, der sagt, wer was tun muss.
 

Und dann gab es das agile Manifest. Was heißt agil in Ihrem Verständnis? 

Hoch diszipliniert und hoch professionell arbeiten, gleichzeitig aber sehr wendig sein und auf wechselnde Anforderungen reagieren, indem man immer wieder anhält. Man kann Scrum darin auch mit den Martial Arts, mit den Kampfkünsten, vergleichen. Unser Auge sieht dabei nur eine fließende Bewegung, in Wirklichkeit stehen die Kämpfer immer wieder, finden ihr Zentrum.
Genauso ist das bei Scrum. Man macht diesen Sprint, und dann steht die Entwicklung quasi für einen Augenblick: Man hat zwei Wochen gearbeitet, alles ist fertig; man macht eine Retrospektive und fängt dann wieder an. Deswegen kann man auch ständig die Richtung ändern. Weil man etwas abgeschlossen hat, kann man wieder etwas anderes machen.
 

Von Anhängern des traditionellen Projektmanagements wird Scrum noch immer als Kampfansage interpretiert? 

Ja, das liegt natürlich auch an der Entstehungsgeschichte. In den 1990er-Jahren wurden Projektmanagementzertifizierungen modern - das gab es GPM, PMI, APM, IPMA und was weiß ich. Scrum war eine Bewegung von Rebellen. Scrum ging von Leuten aus, die einfach nur in Ruhe arbeiten wollten. Die keine Lust mehr hatten, dass Projektmanager ihnen ständig sagen, was sie zu tun haben, obwohl sie - wie meistens, wenn man ehrlich ist - keine Ahnung von der Materie haben. Scrum entstand aus einer Ablehnung des traditionellen Projektmanagements. Und in Reaktion auf seine Schwächen.
Denn Projektmanagement hat eben nicht dazu geführt, dass Projekte besser funktionieren. Sondern dazu, dass immer mehr darüber nachgedacht wird, wer was wann genau liefern muss und wie. Unheimlich viel dreht sich um Kosten, um Anforderungen, um Termine, um Pläne, um Kontrolle und, und, und. Bei Scrum hingegen spielt es keine Rolle, ob ich im Plan liege, sondern ob ich was geliefert habe. Das liegt in der Verantwortung jedes Mitarbeiters.
Und es ist ein echter Paradigmenwechsel, vergleichbar der kopernikanischen Wende. Bis dahin dachte man, dass die Erde der Mittelpunkt des Universums ist. Aber man hatte große Schwierigkeiten, die Planetenbahnen zu berechnen - bis Kopernikus auf die Idee kam, die Sonne in den Mittelpunkt zu rücken. Ähnlich im Projektmanagement. Dort wird immer mehr geplant, um alles richtig zu machen; es werden immer mehr Prozesse aufgesetzt, es wird alles immer komplizierter, aber es bringt nicht die erwünschten Ergebnisse. Denn Projektmanagement läuft in die falsche Richtung. Es ist an der Zeit, etwas ganz anderes zu machen und das Team in den Mittelpunkt zu stellen. Weg von der Verwaltung der Ressourcen, hin zum Team, das allein klarkommen muss!
 

Scrum hat sich bislang im Umfeld von Software- und Produktentwicklung entfaltet, wird nun aber plötzlich von Leuten in Beratung und Management als praktischer Gegenentwurf zu Befehls- und Kontrollorganisationen wahrgenommen - stimmt dieser Eindruck? 

Sie haben ganz recht. Natürlich nehmen die Berater das jetzt wahr - genau die Berater, die bis jetzt Projektmanagement, Requirement Engineering und was weiß ich nicht alles gepredigt haben. Sie denken plötzlich darüber nach, ob sie nicht was mit Scrum machen sollten - weil hier ein Markt entstanden ist.
Viel spannender ist aber, dass nun viele Firmen erkennen, dass dieses neue Modell ihnen die Erfolge bringt, die sie anstreben. Nämlich Transparenz: das Wissen, wo die Projekte stehen. Frühzeitig zu erkennen, dass ein Projekt nicht funktioniert, weil nicht die richtigen Ressourcen vorhanden sind oder man nicht schnell genug ist. Scrum ist hier erfolgreich. Immer mehr Firmen, auch die ganz großen, ob das nun BMW, Mercedes oder die Commerzbank ist, stellen plötzlich fest: Es funktioniert besser. Und plötzlich nehmen alle wahr: Oh, da passiert was!
 

Wer schon in selbstorganisierten Gruppen abseits des traditionellen Projektmanagements gearbeitet hat, wird die Vorgehensweise nicht so ungewöhnlich finden ... 

... mir haben Leute auch schon berichtet, sie seien immer schon so ähnlich vorgegangen; das sei doch nur gesunder Menschenverstand. Das stimmt.
 

Und heute ist auch in den Organisationen etwas in Bewegung gekommen? 

Ja. In Deutschland hat es recht lange gedauert, aber heute ist der Punkt erreicht. Es scheint so was wie ein Zeitgeist zu sein. In den letzten Monaten wird viel über den Unterschied zwischen Kompliziertheit und Komplexität geschrieben, über ein anderes Management, über kulturelle Faktoren, über mehr und besseres Teamwork, über Firmen, die gar kein Management mehr haben, die komplett organisationsgesteuert arbeiten. Da ist anscheinend eine Strömung im Gange.
 

Was kann man von Scrum lernen - für das Funktionieren von Organisationen jenseits von Befehl und Kontrolle? 

Das Vertrauen in die Mitarbeiter stärken! Denn wir haben es ja mit Wissensarbeitern zu tun. Denen kann man nicht sagen, wie sie zu arbeiten haben, sondern man kann nur ihre Kreativität fördern. Ein Manager hat also den Leuten nicht zu sagen, was sie zu tun haben - im Sinne von Aufgaben -, sondern in welche Richtung die Organisation gehen möchte: Was ist unser großes Ziel? Und er hat Strukturen zu schaffen, in denen Selbstorganisation funktioniert. Er soll Rahmenbedingungen so setzen, dass ein normaler Mensch vernünftig arbeiten kann. Und dass Menschen sich entfalten können.
 

Steht dahinter so was wie eine Vision, wie Menschen zusammenarbeiten sollten? 

Für mich persönlich schon. Wir müssen die Menschen respektieren und sie als Erwachsene behandeln. Erwachsene dürfen Entscheidungen für ihr gesamtes Leben treffen. Sie dürfen kaufen, was sie wollen. Sie dürfen Kinder in die Welt setzen. Aber wenn sie in die Firma gehen, dürfen sie nicht mal entscheiden, ob sie 500 Euro ausgeben dürfen. Sie werden in Organisationen entmündigt.
Entscheidend ist der Respekt vor dem Einzelnen. Menschen sind kreativ. Sie wollen miteinander arbeiten, wenn man ihnen einen Sinn gibt. Die Werte von Scrum finden sich bereits in dem ersten Buch: Wir müssen ehrlich, respektvoll, couragiert und offen miteinander umgehen und uns dabei auf das Wesentliche fokussieren. Und wir müssen auch den Mut haben, Entscheidungen zu treffen und dafür Verantwortung zu übernehmen. Das schließt auch ein, sagen zu können, was nicht funktioniert. Ja, dahinter steht schon ein Menschenbild.