Die Droge

Zwanzig Jahre dieselbe Dysfunktion — Teil 1: 2002–2006

2002: Sommer

2002, Sommer.

Im Sommer 2002 suchte ich im Netz nach neuen Ideen zum Projektmanagement. Ich fand einen Artikel von Alistair Cockburn. Dann las ich Jim Highsmith, Ken Schwaber, Kent Beck. Dann das Agile Manifesto. Und dann probierte ich es aus.

Ich schrieb später: „Es war wie eine Droge." Das stimmt. Aber es war mehr als das. Es war die Antwort auf eine Frage, die ich seit Jahren mit mir herumgetragen hatte. Nicht: Wie macht man Projekte richtig? Sondern: Warum machen alle Projekte falsch, obwohl sie es besser wissen?

Ein Jahr zuvor, im Februar 2001, hatten sich siebzehn Leute in einer Ski-Lodge in Snowbird, Utah, getroffen. Sie kamen aus verschiedenen Lagern — XP, Scrum, Crystal, DSDM. Sie konnten sich auf fast nichts einigen. Außer auf vier Sätze. Diese vier Sätze wurden das Agile Manifesto. Im selben Jahr erschien Cockburns Agile Software Development — das erste Buch, das versuchte, die verschiedenen Stämme unter einem Dach zu vereinen (Cockburn, 2001).

Ich war nicht dabei. Aber ich las die vier Sätze und dachte: Das ist es. Endlich sagt jemand, was ich seit Jahren spüre.

Warum ich suchte

Warum ich suchte.

Ich war damals bei der One. Telekommunikation. Wien. Ich hatte Internet und Zeit und eine Ahnung, die mich nicht losließ: dass Projektmanagement, so wie wir es alle gelernt hatten, nicht funktionierte.

Nicht dass die Standards falsch waren. PMI, PMBOK, die europäische Zertifizierung — das war alles nicht verkehrt. Es war logisch. Es war ordentlich. Es war durchdacht. Nur: Es funktionierte nicht, wenn man nicht sehr fluide damit umging. Und niemand ging fluide damit um. Alle gingen starr damit um. Alle hielten sich an den Plan, obwohl der Plan nach zwei Wochen nicht mehr stimmte.

Ich nannte das, was ich stattdessen beobachtete: Improvisation. In jedem Projekt, das ich kannte, wurde improvisiert. Ständig. Heimlich. Weil es anders nicht ging. Aber offiziell existierte die Improvisation nicht. Offiziell gab es den Plan.

Ich wollte Projektmanagement auf neue Füße stellen. Ich war der Meinung, dass Menschen in Teams miteinander gut arbeiten können. Dass wir ein Projektmanagement brauchen, das nicht auf Vorhersage basiert, sondern auf dem, was tatsächlich passiert. Ein improvisierendes Projektmanagement. Das war das Wort, das ich hatte, bevor ich Scrum fand.

Dann fand ich Scrum. Und Scrum hatte die besseren Wörter.

2002: Das erste Team

2002. Das erste Team.

Ich erinnere mich an mein erstes Scrum-Team. 2002. Gillian, Sven, Graig, Jakob, Niki und Marc. Mein Chef Michael Schindelar ließ uns einfach ausprobieren. Keine Genehmigung. Kein Business Case. Kein Proof of Concept. Er sagte: Macht mal.

Das war Führung. Nicht die Art, die ich in meinen Trainings erklärte. Sondern die einfachste Art überhaupt: Jemandem vertrauen. Raum geben. Aus dem Weg gehen.

Ich brauchte fünfzehn Jahre, um zu verstehen, dass dieses „Aus-dem-Weg-Gehen" die anspruchsvollste Führungsleistung ist, die es gibt. Es sieht aus wie Nichtstun. In Wirklichkeit erfordert es eine präzise Einschätzung, wann das Team Raum braucht und wann Richtung. Schindelar konnte das. Intuitiv. Ohne Modell. Ohne Zertifikat.

Und ich zitierte damals Benjamin Zander: „This is the most important moment right now. Which is: We are about to contribute." Beitragen. Nicht beeindrucken. Nicht den nächsten Job sichern. Beitragen.

Das habe ich 2004 geschrieben. Und 2008. Und 2014. Und gestern.

2004: schrieb ich meinen ersten Blogpost

2004.

2004 schrieb ich meinen ersten Blogpost. Auf einer PmWiki-Seite. glogerconsulting.de. Kein Mensch hat das gelesen.

Ich war damals der weltweit erste zertifizierte Scrum-Trainer. Das klingt heute beeindruckend. Damals hieß es: Du bist der Einzige, der dieses Zeug erklärt, und niemand weiß, was du meinst. Die Scrum Alliance war gerade gegründet worden. Es gab weltweit vielleicht fünfzig Certified ScrumMaster. Heute sind es über eine Million.

Was ich meinte: Hört auf, eure Leute wie Maschinen zu behandeln. Hört auf, neun Monate zu planen und dann drei Jahre zu scheitern. Hört auf, Projekte mit offenen Augen an die Wand zu fahren.

Im Oktober 2004 trainierte ich meine ersten Certified ScrumMaster in Wien. Im November zehn weitere bei Web.de in Karlsruhe. Ich reiste. Brasilien, Skandinavien, England. Ich erklärte überall dasselbe: Der ScrumMaster ist kein Projektmanager. Er beseitigt Hindernisse. Er coacht. Er führt, indem er dient.

2006: Die Zahl

2006. Die Zahl.

Auf meiner Website stand: „Do you want to get a 400 Percent productivity gain within 3 months? Then implement Scrum."

Vierhundert Prozent. Ich glaubte das. Jeff Sutherland glaubte das. Er sagte 2006, dass eine Produktivitätssteigerung um das Zwei- bis Vierfache für Scrum-Teams unproblematisch sei. Das Zehnfache sei das eigentliche Ziel (Sutherland, 2006).

Das Verrückte: Es stimmte. Nicht als Versprechen. Als Möglichkeit. Ich hatte eine Studie im Kopf, die mich elektrisiert hatte. James Coplien hatte 1994 das Borland-Team analysiert — acht Entwickler, eine Million Zeilen Code, 31 Monate. Siebenunddreißigmal produktiver als der Durchschnitt. Sein Befund: dichte Kommunikation. Jeden Morgen zwei Stunden zusammensitzen. Fehler besprechen. Maßnahmen beschließen. Dann programmieren (Coplien, 1994).

Nicht die Methode machte den Unterschied. Die Dichte der Kommunikation machte den Unterschied.

Später schrieb ich auf dem Blog: „Kleine Zellen aus fünf bis sieben Mitarbeitern sind hoch produktiv. Studien haben das belegt" (Gloger, 2010, Blog: „Scrum Executive Briefing"). Das war die Essenz. Aber die Unternehmen hörten „400 Prozent" und dachten: Ich kaufe das. Und sie kauften es. Und sie bekamen Zertifikate. Und sie bekamen keine 400 Prozent.

Denn das funktionierte nur, wenn die Organisation bereit war, sich selbst anzuschauen. Und das war sie fast nie.

2006: Der Markt

2006. Der Markt.

2006 explodierte der Blog. scrum4you.wordpress.com. Ich schrieb über alles: Sprint-Planung, Product Backlog, Team-Zusammenstellung, Impediments. Die Community wuchs. In den USA gab es die ersten Agile-Konferenzen mit tausend Teilnehmern. Die Scrum Alliance hatte 2004 gerade die Zertifizierungsmaschine angeworfen — ein Modell, das die Branche für die nächsten zwanzig Jahre prägen sollte.

Was niemand sah: Die Zertifizierungsmaschine löste das Führungsproblem nicht. Sie automatisierte nur den Verkauf des Versprechens.

Ich verkaufte mit. Natürlich verkaufte ich mit. Ich war der Erste. Ich war überzeugt. Ich sah, was Scrum in Teams auslösen konnte — die Energie, die Freude, die Ergebnisse. Ich sah auch, dass die Organisation drumherum unberührt blieb. Aber ich dachte: Das kommt noch. Wenn sie erstmal sehen, was möglich ist.

Es kam nicht.

Die Dysfunktionen von 2006 waren dieselben wie die von 2026. Nur kleiner. Noch ohne Etikett. Noch ohne die Sprache, die ich brauchte, um sie zu benennen. Die Sprache kam erst in den nächsten zwanzig Jahren. Die Dysfunktionen blieben.

Nächster Teil: [Ängstliche Wesen (2006–2008)]

Quellen

Quellen:

Cockburn, A. (2001). Agile Software Development. Addison-Wesley.

Coplien, J. O. (1994). Borland Software Craftsmanship: A New Look at Process, Quality and Productivity. Proceedings of the 5th Annual Borland International Conference.

Gloger, B. (2010). Scrum Executive Briefing [Blogpost]. borisgloger.com.

Sutherland, J. (2006). Scrum and Hyperproductivity. Präsentation, Agile 2006.

Du liest als Gast — willkommen. Als Leser bekommst du „Den Brief": persönliche Werkstattnotizen, 2x im Monat, direkt in dein Postfach. → Leser werden