Vorwort

Warum Scrum?

Ich habe Scrum vor 20 Jahren gemeinsam mit Ken Schwaber entwickelt, um die Softwareentwicklung in der Technologiebranche zu beschleunigen und sie verlässlicher und erfolgreicher zu machen. Bis dahin - und das galt sogar noch im Jahr 2005 - wurden die meisten Softwareentwicklungsprojekte mithilfe des Wasserfall-Modells vorangetrieben. Ein Projekt durchläuft dabei einzelne, scharf voneinander abgegrenzte Entwicklungsschritte, an deren Ende die Auslieferung an den Kunden oder Nutzer steht. Dieser Prozess ist nicht nur langsam und unberechenbar, sondern fördert oft auch keinerlei Produkt zutage, das tatsächlich gebraucht und nachgefragt würde. Monatelange oder gar jahrelange Lieferverzögerungen waren die Regel. Aufgrund der zu Projektbeginn angefertigten Stufenpläne, die in beruhigend detaillierten Gantt-Charts ausgebreitet wurden, wiegte sich das Projektmanagement in dem Glauben, dass man den Entwicklungsprozess schon unter Kontrolle habe - doch fast immer wurden Termine und Kostenrahmen schnell und nachhaltig gesprengt.
Um diese Mängel zu überwinden, entwickelte ich 1993 eine neue Herangehensweise: Scrum. Sie verkörpert einen radikalen Bruch mit den vorschriftslastigen Projektmanagementmethoden der Vergangenheit, bei denen der Vorgesetzte Anweisungen erteilt. Scrum ähnelt vielmehr evolutionären, adaptiven und selbstkorrigierenden Systemen. Das Scrum-Gerüst hat sich umgehend zur Standardmethode für die Konzeption neuer Software und Produkte in der Technologiebranche entwickelt. Doch während Scrum große öffentliche Erfolge beim Management von Soft- und Hardwareprojekten in Silicon Valley feiert, ist es bis heute im allgemeinen Wirtschaftsleben relativ unbekannt. Und deshalb habe ich dieses Buch geschrieben - um Unternehmen außerhalb der Technologiebranche das Managementsystem Scrum vorzustellen und zu erläutern. In diesem Buch beschreibe ich die Entstehung von Scrum, das im Toyota-Produktionssystem und in der OODA-Schleife der Kampfflieger wurzelt. Ich erläutere, wie wir Projekte um kleine Teams herum organisieren und warum das eine so effektive Arbeitsweise darstellt. Sie erfahren, wie wir Projekte priorisieren, einwöchige bis einmonatige 'Sprints' auf die Beine stellen, um ein Projekt voranzutreiben und alle Teammitglieder in die Verantwortung mit einzubinden, und im Tagesrhythmus kurze Daily Scrums abhalten, um unsere Fortschritte im Auge zu behalten und den zwangsläufig auftretenden Herausforderungen zu begegnen. Und ich zeige Ihnen, wie Scrum das Prinzip der kontinuierlichen Verbesserung mit dem Konzept verbindet, minimal funktionsfähige Produkte zu entwickeln, um so eine schnelle Rückmeldung des Kunden einzuholen, anstatt damit bis zur vollständigen Fertigstellung zu warten. Wie Sie auf den folgenden Seiten sehen werden, lässt sich mithilfe von Scrum alles Mögliche erreichen - vom Bau eines erschwinglichen Autos mit sehr niedrigem Benzinverbrauch bis zur Überführung der Datenbanksysteme des FBI ins 21. Jahrhundert.
Ich lade Sie herzlich ein weiterzulesen. Sie werden erkennen, wie Scrum Ihr Unternehmen bei der Umgestaltung seiner Arbeits-, Entwicklungs- und Planungsprozesse unterstützen und ihm zu neuen Herangehensweisen verhelfen kann. Ich bin der festen Überzeugung, dass Scrum das Potenzial besitzt, in nahezu jeder Branche die Prozesse von Grund auf umzugestalten - genauso wie es die Innovationsfähigkeit und die Entwicklungszeiten bei einer atemberaubenden Vielzahl von Unternehmen und Produkten aus Silicon Valley und der restlichen Technologiewelt revolutioniert hat.
Jeff Sutherland

Kapitel 1
Unsere Welt ist aus den Fugen geraten

Jeff Johnson war sich ziemlich sicher, dass dieser Tag für ihn nichts Gutes bereithielt. Am 3. März 2010 hatte das FBI sein größtes und ehrgeizigstes Modernisierungsvorhaben zu Grabe getragen - ein Vorhaben, das ursprünglich ein zweites 9/11 verhindern sollte, sich dann aber in eines der schlimmsten Softwaredebakel aller Zeiten verwandelte. Mehr als ein Jahrzehnt hatte das FBI in die Aufrüstung seines Computersystems investiert, und doch sah es so aus, als würde dieses Projekt scheitern. Schon wieder. Nur dass diesmal er die Verantwortung trug.
Sieben Monate zuvor hatte er das Gebäude des FBI erstmals betreten, auf Vorschlag des neuen IT-Leiters Chad Fulgham, eines früheren Arbeitskollegen bei Lehman Brothers. Zu diesem Zeitpunkt war Johnson stellvertretender Leiter der Abteilung für IT-Technik. Sein Büro befand sich auf der obersten Etage des J. Edgar Hoover Buildings mitten in Washington, D.C., mit Blick auf das Washington Monument. Er ahnte nicht, dass er einen Großteil der nächsten zwei Jahre in einem fensterlosen Kellerraum mit Wänden aus Schlackenbeton zubringen würde, um etwas zu reparieren, das gemeinhin als irreparabel galt.
'Die Entscheidung fiel uns nicht leicht', sagt Johnson heute. Sein Vorgesetzter und er hatten beschlossen, die Niederlage einzuräumen und einem Programm den Todesstoß zu versetzen, das schon ein knappes Jahrzehnt und mehrere Hundert Millionen US-Dollar verschlungen hatte. Es erschien nun sinnvoller, das Projekt hausintern fertigzustellen. 'Aber es musste erledigt werden, und zwar gut.'
Bei dem Projekt handelte es sich um das sehnlichst erwartete Computersystem, welches das FBI ins moderne Zeitalter katapultieren würde. Im Jahre 2010, inmitten der Ära von Facebook, Twitter, Amazon und Google, legte das FBI noch immer den überwiegenden Teil seiner Berichte in Papierform ab. Seine Dokumentenverwaltung, das sogenannte Automated Case Support System, lief auf riesigen Großrechnern, die irgendwann in den achtziger Jahren des letzten Jahrhunderts mal hochmodern gewesen waren. Manche Sonderermittler nutzten es nicht einmal - im Zeitalter von Terrorattacken und extrem mobilen Kriminellen war es einfach zu schwerfällig und zu langsam.
Wenn ein FBI-Agent irgendetwas unternehmen wollte - sei es, einen Informanten zu bezahlen, einen Terroristen zu verfolgen oder über einen Bankräuber zu berichten -, musste er im Wesentlichen genauso vorgehen wie schon 30 Jahre zuvor. Johnson beschreibt es so: 'Man erstellte ein Dokument in einem Textverarbeitungsprogramm und druckte es drei Mal aus. Ein Ausdruck wanderte die Befehlskette hoch, ein zweiter wurde abgeheftet für den Fall, dass der erste verloren ging. Auf dem dritten musste der Agent mit Rotstift - im Ernst, mit einem Rotstift! - die Schlüsselwörter für die hausinterne Datenbank markieren. Man musste also seinen eigenen Bericht indexieren.'
Wurde der Antrag genehmigt, kam der Ausdruck, mit einer Nummer versehen, von oben zurück. Eine schlichte Nummer auf einem Stück Papier diente dem FBI zur Verwaltung aller seiner Vorgänge. Diese Methode war so altbacken und durchlässig, dass man das Versagen der Behörde im Vorfeld der Terroranschläge vom 11. September 2001 teilweise darauf zurückführte. Das FBI hatte es nicht vermocht, einen Zusammenhang zwischen der Einreise mehrerer Al-Qaida-Aktivisten in den Wochen und Monaten vor den Anschlägen zu erkennen. Das eine Büro verdächtigte einen der späteren Terroristen. Ein zweites wunderte sich, dass so viele verdächtige Ausländer Flugstunden nahmen. Und ein drittes überwachte zwar jemanden, behielt das aber für sich. Niemand im FBI fügte die Puzzlesteine je zusammen.
Die mit der Untersuchung der Anschläge beauftragte Kommission ging intensiv der Frage nach, warum diese nicht im Vorfeld verhindert werden konnten. Dabei stellte man fest, dass die Analysten gar keinen Zugang zu den Informationen erhielten, die sie analysieren sollten. Im Untersuchungsbericht heißt es: 'Der beklagenswerte Zustand der Informationssysteme des FBI führte dazu, dass der Zugang zu Informationen von den persönlichen Beziehungen des Analysten zu den betreffenden Informationsträgern in einer operativen Einheit oder Gruppe abhing.'
Bis zu den Anschlägen des 11. September hatte das FBI noch nie eine Gesamtbewertung der terroristischen Bedrohung, die sich gegen die USA richtete, vorgenommen. Das hatte vielerlei Gründe, die von einer Konzentration der Mitarbeiter auf die eigene Karriere bis zu der Neigung reichte, Informationen zu horten. Doch der Bericht sah den vermutlichen Hauptgrund für das dramatische Versagen der Behörde im Vorfeld der Terroranschläge in der schwachen technologischen Ausrüstung des FBI. 'Die Informationssysteme des FBI waren bedauerlicherweise höchst unzulänglich', schließt der Bericht der Untersuchungskommission. 'Das FBI war nicht in der Lage, sich sein eigenes Wissen zu erschließen: Es verfügte über keinen wirksamen Mechanismus, um sein institutionelles Wissen zu verarbeiten und zu teilen.'
Als manche US-Senatoren daraufhin dem FBI einige unangenehme Fragen stellten, entgegnete der Geheimdienst im Wesentlichen: 'Keine Sorge, unser Modernisierungsplan ist schon in Arbeit.' Jener Plan, das sogenannte Virtual Case File System (VCF), sollte alles ändern. Natürlich ließ man es sich nicht nehmen, auch diese Krise weidlich auszunutzen, und so erklärten die Verantwortlichen, lediglich weitere 70 Millionen US-Dollar zu benötigen, um das bestehende Budget von 100 Millionen US-Dollar aufzustocken. Wer sich die Mühe macht, die damaligen Presseberichte über VCF nachzulesen, stößt häufig auf die Worte revolutionär und Wandel.
Drei Jahre später wurde das Projekt beerdigt. Es funktionierte nicht einmal ansatzweise. Das FBI hatte 170 Millionen US-Dollar an Steuergeldern für den Kauf eines Computersystems verschleudert, das niemals in Betrieb gehen würde - keine einzige Codezeile, keine Anwendung, kein Mausklick. Das Ganze war ein absolutes Desaster. Und es ging hier nicht um einen Fehler von IBM oder Microsoft, sondern um das Leben von Menschen. Patrick Leary, demokratischer Senator aus Vermont und seinerzeit hochrangiges Mitglied des Justizausschusses des US-Senats, sagte damals der Washington Post:

'Wir verfügten über die notwendigen Informationen, um 9/11 zu stoppen. Es gab sie und man reagierte nicht darauf [...] Die Probleme sind noch immer nicht angegangen worden [...] Vielleicht werden wir erst im 22. Jahrhundert die Technologie des 21. Jahrhunderts erhalten.'1

Es ist bezeichnend, dass viele der Leute, die zur Zeit des VCF-Desasters im FBI saßen, heute nicht mehr dort anzutreffen sind.
Im Jahr 2005 gab das FBI den Start eines neuen Programms mit dem Namen 'Sentinel' bekannt. Diesmal würde es funktionieren. Sicherungsmaßnahmen, Mittelzuweisungsverfahren, Kontrollmechanismen: alles perfekt. Das FBI hatte seine Lektion gelernt. Die Kosten? Läppische 451 Millionen US-Dollar. Und schon 2009 würde alles wie am Schnürchen laufen.
Was konnte da noch schiefgehen? Im März 2010 landete die Antwort auf diese Frage auf dem Schreibtisch von Jeff Johnson. Lockheed Martin, die mit der Implementierung des Sentinel-Systems beauftragte Firma, hatte bereits 405 Millionen US-Dollar ausgegeben. Das Projekt war erst zur Hälfte fertiggestellt und schon ein Jahr im Verzug. Einem unabhängigen Gutachten zufolge würden bis zu seiner Vollendung noch einmal sechs bis acht Jahre vergehen, und die Steuerzahler würden im günstigsten Fall mit weiteren 350 Millionen US-Dollar belastet.
Johnsons Aufgabe bestand darin, einen Ausweg aus dieser Situation zu finden.
Das FBI-Desaster und seine spätere Lösung haben mich dazu inspiriert, dieses Buch zu schreiben. Das Problem war nicht, dass die Beteiligten dumm gewesen wären, es dem FBI an den richtigen Mitarbeitern gefehlt oder deren Arbeitsmoral zu wünschen übrig gelassen hätte. Es mangelte auch nicht am nötigen Wettbewerbsgeist. Selbst die Technologie trug keine Schuld.
Das Problem war vielmehr die Art und Weise, wie die Menschen arbeiteten - genauer gesagt, wie die meisten Menschen arbeiten. Wir alle denken, dass Arbeit auf eine ganz bestimmte Weise erledigt werden muss, weil man es uns so beigebracht hat.
Wenn Sie nun erfahren, was geschah, dann klingt alles zunächst sehr plausibel: Bevor sie ihr Angebot erstellten, setzten sich die Leute bei Lockheed zunächst hin, gingen die Anforderungen durch und planten ein System, das alle diese Anforderungen erfüllen würde. Zahlreiche intelligente Menschen arbeiteten monatelang eine Aufgabenliste aus. Weitere Monate vergingen mit der Ausführungsplanung. Wunderschöne Charts entstanden, auf denen man ablesen konnte, was alles zu tun war und wie lange jeder einzelne Schritt dauern würde. Mit sorgsam ausgewählten Farben wurde dargestellt, wie jeder Projektabschnitt nach Art eines Wasserfalls in den nächsten herabstürzen würde (siehe Abbildung 1).
Diese Charts werden nach ihrem Erfinder, Henry Gantt, als Gantt-Charts bezeichnet. Mit dem Aufkommen von PCs in den achtziger Jahren wurde es leicht, diese verschachtelten Charts zu erstellen und sie so richtig komplex zu machen. Seitdem haben sie sich in wahre Kunstwerke verwandelt. Jeder Schritt eines Projekts kann nun detailliert dargestellt werden. Jeder Meilenstein. Jeder Liefertermin. Diese Charts können einen wirklich beeindrucken. Ihr einziges Problem: Sie sind grundsätzlich und immer falsch.
Henry Gantt erfand seine berühmten Charts um das Jahr 1910 herum. Eingesetzt wurden sie erstmals im Ersten Weltkrieg von General William Crozier, dem damaligen Chef des Waffenamts der US-Armee. Jeder, der sich mit diesem Krieg beschäftigt hat, weiß, dass er nicht gerade von effizienter Organisation gekennzeichnet war. Ich habe nie ganz verstanden, wie ein Artefakt des Ersten Weltkriegs zum Standardwerkzeug des Projektmanagements im 21. Jahrhundert werden konnte. Die Stellungskriege sind Geschichte, doch seltsamerweise bleiben die ihnen zugrundeliegenden Konzepte weiterhin populär.
Es ist einfach so verlockend: Alle Arbeitsschritte eines riesigen Projekts werden anschaulich ausgebreitet. Zahlreiche mir persönlich bekannte Unternehmen beschäftigen Mitarbeiter, deren einzige Aufgabe darin besteht, den Gantt-Chart täglich zu aktualisieren. Leider scheitert dieser hochelegante Plan regelmäßig an der Wirklichkeit. Doch anstatt ihn zu verwerfen oder zumindest kritischer zu betrachten, werden Leute angeheuert, die den Anschein erwecken sollen, als würde er funktionieren. Im Grunde heißt das nichts anderes, als dass man Leute dafür bezahlt, einen anzulügen.
Dieses unglückliche Muster erinnert an die Berichte, die das sowjetische Politbüro in den achtziger Jahren erhielt, kurz vor dem vollständigen Zusammenbruch der UdSSR. Heute wie damals gelten die Berichte mehr als die Realität, die sie beschreiben sollen. Weichen beide voneinander ab, sind nicht die Charts das Problem, sondern die Realität.
Als Kadett in der West Point Academy schlief ich in Dwight Eisenhowers ehemaligem Zimmer. Nachts wachte ich gelegentlich von dem Licht der Straßenlaternen auf, die eine goldene Plakette über dem Kaminsims anstrahlten. 'Hier schlief Dwight D. Eisenhower', war darauf zu lesen. Und ich dachte an Eisenhowers Feststellung, dass man den Kampfeinsatz zwar planen müsse, dieser Plan sich aber stets in Rauch auflöse, sobald der erste Schuss gefallen sei. Zumindest er war klug genug, sich nicht auf ein Gantt-Chart zu verlassen.
Lockheed präsentierte dem FBI also diese ganzen wunderbaren Charts, und der Geheimdienst biss an. Schließlich war das Unterfangen ja anscheinend so gut geplant, dass nichts schiefgehen konnte. 'Sehen Sie nur, es steht alles in diesen farbkodierten Balkendiagrammen voller Zeitstempel.'
Doch als Johnson und sein Vorgesetzter, der IT-Leiter Chad Fulgham, im Frühling 2010 den Plan analysierten, erkannten sie sofort, dass er wie alle derartigen Pläne nur ein Fantasiegespinst war. Ein Blick auf die tatsächliche Entwicklung und die bisherigen Ergebnisse offenbarte, dass die Probleme unlösbar waren. Neue Softwarefehler tauchten schneller auf, als sich die alten beheben ließen.
Fulgham teilte dem Generalinspekteur des Justizministeriums mit, dass seine Abteilung das Sentinel-Projekt zum Abschluss bringen könne, sofern man die Entwicklung ins Haus holen und die Anzahl der Entwickler reduzieren dürfe. Man werde dann die anspruchsvollste Hälfte des Projekts in einem Fünftel der Zeit und mit weniger als einem Zehntel des Budgets bewältigen. Die Skepsis, die die gewöhnlich recht trockenen Berichte des Generalinspekteurs an den Kongress durchzog, war mit Händen zu greifen. In ihrem Bericht vom Oktober 2010 erläutern die Wächter des Justizministeriums ihre neun Einwände gegen den Vorschlag und schließen mit den Worten: 'Unser Fazit lautet, dass schwerwiegende Bedenken und Fragen hinsichtlich der Fähigkeit dieses neuen Ansatzes verbleiben, das Sentinel-Projekt budget- und termingerecht sowie mit ähnlicher Funktionalität zu vollenden.'2

Eine neue Denkweise

Dieser neue Ansatz heißt Scrum. Ich habe ihn vor 20 Jahren entwickelt. Heute ist er die einzige bewährte Möglichkeit, Projekten wie diesen wieder auf die Beine zu helfen. Es gibt zwei Möglichkeiten, ein Vorhaben durchzuführen: entweder unter Verwendung des alten 'Wasserfall-Modells', das Millionen verschlingt, ohne einen Mehrwert zu generieren, oder mithilfe des neuen Ansatzes, der mit weniger Menschen, in kürzerer Zeit und zu niedrigeren Kosten mehr leistet. Vielleicht klingt das zu schön, um wahr zu sein, doch die Praxis zeigt, dass es funktioniert.
Vor 20 Jahren war ich verzweifelt. Ich benötigte eine neue Herangehensweise an Arbeit und erkannte nach intensiver Forschung und zahllosen Experimenten, dass wir menschliches Streben ganz neu organisieren müssen. Mein Ansatz ist weder kompliziert noch schwarze Magie; alles ist schon früher diskutiert worden. Bereits im Zweiten Weltkrieg untersuchte man, wie Menschen am besten arbeiten. Doch aus irgendeinem Grund machte sich niemals jemand die Mühe, die Puzzlesteine zusammenzufügen. In den letzten beiden Jahrzehnten habe ich genau das versucht, und heute ist meine Methode auf dem Gebiet der Softwareentwicklung, wo sie erstmals zum Einsatz kam, omnipräsent. Das Konzept hat die Arbeitsweise von Internetgiganten wie Google, Amazon und Salesforce.com, aber auch von kleinen, noch unbekannten Start-ups dramatisch verändert.
Das Erfolgsrezept dieses Ansatzes ist sehr einfach: Ich habe untersucht, wie die Menschen tatsächlich arbeiten - und nicht, wie sie nach eigenem Bekunden arbeiten. Daneben habe ich die Forschungsergebnisse mehrerer Jahrzehnte Revue passieren lassen, Best Practices aus zahlreichen Betrieben weltweit analysiert und deren erfolgreichste Teams eingehend untersucht. Worauf beruhte ihre Stärke? Was unterschied sie von anderen? Warum leisten manche Teams Großartiges, während andere in der Mittelmäßigkeit verharren?
Dieses Konzept zur Steigerung der Teamleistung habe ich 'Scrum' genannt - warum, wird in späteren Kapiteln noch deutlich. Der Begriff stammt aus dem Rugby und bezeichnet das Zusammenspiel einer Mannschaft mit dem Ziel, den Ball über das Spielfeld zu bewegen. Dazu sind gute Koordination, eine gemeinsame Absicht und ein klares Ziel erforderlich: die perfekte Metapher für das, was Teams meiner Ansicht nach tun sollten.
Gewöhnlich achten Manager bei Projekten jeglicher Art auf zweierlei: Kontrolle und Berechenbarkeit. Dies führt zur Erstellung zahlloser Dokumente, Schaubilder und Charts, genau wie bei Lockheed. Monatelang wird jedes Detail akribisch geplant, damit ja keine Fehler passieren, der Kostenrahmen eingehalten wird und die Leistungen pünktlich erbracht werden.
Doch dieses rosarote Szenario tritt in Wirklichkeit nie ein. Die ganzen Anstrengungen, die in die Planung, die Bekämpfung von Unsicherheiten und den Versuch, das Unvorhersehbare vorauszuahnen, fließen, sind für die Katz. Bei jedem Projekt tauchen plötzlich Probleme auf und gibt es Momente der Inspiration. Wer menschliches Streben welcher Art auch immer in farbkodierte Charts und Schaubilder zu pressen versucht, handelt töricht und ist zum Scheitern verurteilt. So funktioniert der Mensch nicht, und so kommen auch Vorhaben nicht voran, lassen sich weder Ideen verwirklichen noch großartige Leistungen erzielen.
Stattdessen bleiben frustrierte Menschen zurück, die ihre Ziele nicht umsetzen können. Projekte verzögern sich, werden teurer als geplant oder scheitern, wie so oft, gänzlich. Das gilt insbesondere für Teams, die mit einer kreativen Neuentwicklung befasst sind. In der Regel weigert sich das Management so lange, die abschüssige Bahn in Richtung eines Fehlschlags zu erkennen, bis Millionenbeträge und Tausende von Arbeitsstunden in den Sand gesetzt wurden.
Scrum untersucht, warum es so zeitaufwändig und so schwierig ist, Aufgaben zu erledigen, und warum es uns so schwerfällt, den voraussichtlichen Zeit- und Arbeitsaufwand für ein Vorhaben einzuschätzen. Der Bau der Kathedrale von Chartres nahm 57 Jahre in Anspruch. Kein Zweifel, dass zu Beginn des Projekts die Steinmetze den Bischof ansahen und sagten: 'Zwanzig Jahre, höchstens. Kriegen wir wahrscheinlich in fünfzehn hin.'
Scrum begrüßt Unsicherheit und Kreativität mit offenen Armen. Es strukturiert den Lernprozess und hilft dadurch Teams, zu beurteilen, was sie geleistet haben und - ebenso wichtig - wie das gelingen konnte. Das Scrum-Gerüst nutzt die Funktionsmechanismen von Teams aus und gibt ihnen einen Werkzeugkasten an die Hand, mithilfe dessen sie sich selbst organisieren und das Tempo sowie die Qualität ihrer Arbeit rasch steigern können.
Die Grundidee von Scrum ist sehr einfach: Wenn man ein Projekt beginnt, warum sollte man dann nicht regelmäßig überprüfen, ob die Richtung noch stimmt und man Leistungen erbringt, die tatsächlich gebraucht werden? Warum nicht prüfen, ob es vielleicht Mittel und Wege gibt, um besser und schneller voranzukommen, und welche Hindernisse dem womöglich entgegenstehen?
Dieser Prozess wird als Prüfungs- und Anpassungszyklus (engl. inspect and adapt) bezeichnet: Ab und zu hält man inne, analysiert das bisherige Vorgehen und prüft, ob es noch immer zielführend ist und ob es sich nicht vielleicht verbessern ließe. Ein simples Konzept, dessen Umsetzung allerdings viel Gehirnschmalz, Selbstbeobachtung, Ehrlichkeit und Disziplin erfordert. Dieses Buch möchte Ihnen zeigen, wie es geht, auch außerhalb der Softwarebranche. Ich kenne erfolgreiche Scrum-Einsätze im Automobilbau, in Wäschereien, im Unterricht an Schulen und Universitäten, beim Bau von Raketenschiffen oder bei der Organisation einer Hochzeit - und selbst meine Frau nutzt Scrum, um sicherzustellen, dass die 'Schatz-bitte-erledigen'-Liste am Wochenende auch immer abgearbeitet wird.
Das Ergebnis des Scrum-Prozesses - das Designziel, wenn Sie so wollen - sind Teams, denen es gelingt, ihre Produktivität dramatisch zu steigern. In den letzten 20 Jahren habe ich immer wieder solche Teams geformt. Ich war CEO, CTO oder technischer Leiter eines guten Dutzends von Unternehmen, von kleinen Start-ups mit nur wenigen Leuten in einem einzigen Raum bis zu großen Firmen mit einem weltweiten Netz von Niederlassungen. Hunderte weitere Unternehmen habe ich beraten und gecoacht.
Die Ergebnisse sind oft so beeindruckend, dass große Marktforschungs- und Analysefirmen wie Gartner oder Standish den alten Arbeitsstil heute als obsolet bezeichnen. Unternehmen, die verzweifelt an der erprobten, aber falschen Vorstellung festhalten, alles ließe sich anordnen, kontrollieren und exakt vorhersagen, sind zum Scheitern verurteilt, wenn ihre Wettbewerber Scrum verwenden. Der Unterschied ist einfach zu groß. Wagniskapitalfirmen wie OpenView Venture Partners, ein Bostoner Unternehmen, dessen Berater ich bin, bezeichnen den Wettbewerbsvorteil von Scrum als so gewaltig, dass man sich nicht leisten könne, darauf zu verzichten. Das sind keine Gutmenschen, sondern äußerst kritische Finanziers, doch sie sagen: 'Die Ergebnisse sind eindeutig. Als Unternehmen hat man nur die Wahl zwischen Wandel und Untergang.'

< Löscheinsatz beim FBI

Das erste Problem, dem das Sentinel-Team beim FBI begegnete, war der Umstand, dass jede Veränderung zu einer Neuverhandlung der Verträge mit Lockheed Martin führte. Monatelang entwirrten Jeff Johnson und Chad Fulgham daher sämtliche Verträge, zogen den Entwicklungsprozess an sich und reduzierten den Mitarbeiterstab von mehreren Hundert Menschen auf weniger als 50. Das Kernteam war sogar noch kleiner.
In der ersten Woche taten sie, was viele Menschen in dieser Situation tun würden: Sie druckten die gesamte Anforderungsdokumentation aus. Bei großen Projekten sind das oft Hunderte oder gar Tausende von Seiten. Ich habe bereits Papierstöße gesehen, die über einen Meter hoch waren. Immer wieder erlebe ich dasselbe - Textbaustein nach Textbaustein wird kopiert und eingefügt, aber niemand macht sich die Mühe, dieses Konvolut tatsächlich zu lesen. Es ist gar nicht zu schaffen. Und genau das ist der springende Punkt: Das System, das diese Leute etabliert haben, zwingt sie dazu, einem Fantasiegebäude zu huldigen.
'Es gab 1100 Anforderungen. Der Papierstoß war mehr als zehn Zentimeter dick', sagt Johnson. Allein der Gedanke an diese ganzen Dokumente löst in mir Mitleid mit jenen Menschen aus, die vermutlich wochenlang damit beschäftigt waren, diese völlig sinnlosen Dokumente zu erstellen. Das FBI und Lockheed Martin sind nicht die Einzigen - fast bei jedem von mir beratenen Unternehmen habe ich das erlebt. Dieser große Stapel an Sinnlosigkeit verdeutlicht, welch durchschlagende Veränderung Scrum bewirken kann. Niemand sollte sein Leben mit sinnloser Arbeit zubringen. Sie schadet nicht nur dem Geschäft, sondern tötet die Seele.
Mit diesem Papierstoß in der Hand machten sie sich also ans Werk und arbeiteten eine Prioritätenrangfolge der Anforderungen aus. Dieser äußerst wichtige Schritt ist schwieriger, als man denken könnte. Manchmal heißt es nur, alles sei wichtig. Die entscheidende Frage, die sich die Sentinel-Teams stellten, lautet jedoch: Was wirkt sich am stärksten mehrwertsteigernd aus? Das sollte zuerst erledigt werden. In der Softwareentwicklung gibt es eine alte Regel, die auf jahrzehntelanger Forschung beruht, wonach 80 Prozent des Mehrwerts einer beliebigen Software von 20 Prozent der Funktionalitäten bestritten werden. Überlegen Sie einmal: Wann haben Sie zuletzt den Visual Basic Editor in Microsoft Word verwendet? Vermutlich wissen Sie gar nicht, was Visual Basic überhaupt ist, geschweige denn, warum man es verwenden sollte. Doch es existiert, und irgendjemand hat viel Zeit damit verbracht, die Funktion zu implementieren, obwohl sie den Mehrwert von Word garantiert kaum steigert.
Die Priorisierung nach Mehrwert zwingt die Menschen dazu, die wichtigsten 20 Prozent zuerst zu produzieren. Wenn das geschafft ist, bemerken sie oft, dass sie die anderen 80 Prozent nicht wirklich benötigen oder dass manches, was anfangs so wichtig erschien, es eigentlich nicht ist.
Das Sentinel-Team sagte sich: 'Gut, nun arbeiten wir an diesem so wichtigen Riesenprojekt, das schon Hunderte von Millionen Dollar vernichtet hat. Wann wird es fertig sein?' Nach einiger Reflektion versprach man, im Herbst 2011 zu liefern. Im Herbstbericht 2010 des Generalinspektors spricht der Unglaube aus jeder Zeile:

'Das FBI erklärte, die Entwicklung von Sentinel mithilfe einer ?agilen Methodik? vollenden zu wollen, wobei weniger Mitarbeiter des FBI, von Lockheed Martin und der Unternehmen, die einen Großteil der maßgefertigten Bestandteile von Sentinel geliefert haben, zum Einsatz kommen sollen. Insgesamt plant das FBI, die Zahl der mit der Entwicklung von Sentinel befassten Angestellten von circa 220 auf 40 zu reduzieren. Gleichzeitig soll die Anzahl der FBI-Mitarbeiter, die diesem Projekt zugeteilt sind, von 30 auf zwölf sinken. [...] Das FBI hat mitgeteilt, es glaube, Sentinel mit dem verbleibenden Projektbudget von 20 Millionen Dollar und innerhalb von zwölf Monaten nach Einführung des neuen Ansatzes fertigstellen zu können.'3

Die Verwendung des Ausdrucks 'agile Methodik' belegt, wie wenig der Generalinspektor von Scrum verstand. Das Wort 'agil' lässt sich auf eine Klausurtagung im Jahr 2001 zurückführen, bei der ich gemeinsam mit 16 anderen führenden Softwareentwicklern ein Thesenpapier entwarf, das als 'Agiles Manifest' bekannt wurde. Es verkündete folgenden Wertekanon: Menschen vor Prozessen; tatsächlich funktionierende Projekte vor Anforderungsdokumentationen; Zusammenarbeit mit Kunden statt andauernder Verhandlungen; und Reagieren auf Veränderungen, anstatt blind einem Plan zu folgen. Scrum ist das Gerüst, das dazu dient, diesen Wertekanon in die Praxis umzusetzen. Es gibt keine Methodik.
Natürlich war Johnsons Versprechen, in einem Jahr fertig zu sein, ein wenig irreführend. Denn tatsächlich kannte niemand den genauen Termin; man konnte ihn gar nicht kennen. Das FBI wusste nicht, wie schnell seine Teams arbeiten konnten. Immer wieder sage ich Unternehmensleitern: 'Den Termin weiß ich erst dann, wenn ich gesehen habe, wie stark sich die Teams verbessern. Wie schnell sie sein werden. Wie stark sie beschleunigen.'
Natürlich war es ebenso wichtig, dass die Teammitglieder erkannten, was ihren Beschleunigungsprozess behindern konnte. 'Ich kümmerte mich um die Beseitigung von Hindernissen', formuliert es Jeff Johnson. Der Begriff 'Hindernis' (engl. impediment) wurde von jenem Unternehmen geprägt, auf dessen Ideen sich viele der Grundlagen von Scrum zurückführen lassen: Toyota. Genauer gesagt, das von Taiichi Ohno entwickelte Toyota-Produktionssystem.
Ich will mich hier nicht mit den Details aufhalten, doch eines von Ohnos Schlüsselkonzepten war der 'Flow'-Gedanke: Der gesamte Produktionsprozess sollte Ohno zufolge einem ruhigen, aber schnellen Fluss gleichen, und es sei eine der Hauptaufgaben des Managements, Hindernisse zu beseitigen, die sich diesem Fluss entgegenstellen. Alles, was im Wege steht, ist Verschwendung. In seinem Klassiker Das Toyota-Produktionssystem misst Ohno Verschwendung sowohl einen moralischen als auch einen wirtschaftlichen Wert zu:

'Die Behauptung, dass Verschwendung in Zeiten niedrigen Wirtschaftswachstums eher als Verbrechen gegen die Gesellschaft denn als wirtschaftlicher Verlust zu werten sei, ist keinesfalls übertrieben. Die Eliminierung von Verschwendung muss das Hauptziel jedes Unternehmens sein.'4

Ohno beschäftigt sich ausführlich mit den verschiedenen Arten von Verschwendung und Hindernissen, die den Produktionsprozess verzögern können. Damit Scrum seine Wirkung voll entfalten kann, muss es im Topmanagement jemanden geben, der fest davon überzeugt ist, dass Hindernisse gleichsam als Verbrechen zu werten sind. Wir werden später noch sehen, wie genau man Verschwendung aus der Welt schafft. Hier genügt die Feststellung, dass die Eliminierung von Verschwendung geradezu dramatische Wirkungen entfaltet. Dennoch wird oft darauf verzichtet, denn es setzt voraus, dass man ehrlich zu sich selbst und zu anderen ist.
Jeff Johnson wusste, dass er sich genau darum kümmern musste.
Das Sentinel-Team benötigte etwa drei Monate, um den tatsächlichen Projektabschlusstermin zu berechnen. Warum so lange? Erinnern wir uns an den weiter oben erwähnten Prüfungs- und Anpassungsprozess. Scrum setzt sequenzielle Ziele, die in einem festgelegten Zeitraum erreicht werden müssen. Im Falle des FBI einigte man sich auf zweiwöchige Zyklen, wobei am Ende jedes Zyklus abgeschlossene Produktinkremente vorliegen mussten. Es sollte also etwas geben, das funktionierte und jedem Inte?ressierten vorgeführt werden konnte - den Stakeholdern und idealerweise auch jenen Menschen, die später damit arbeiten mussten.
Auf diese Weise erhalten Teams ein zeitnahes Feedback: Stimmt die Richtung? Sind die nächsten Ziele tatsächlich relevant angesichts der Erkenntnisse aus dem gerade abgeschlossenen Zyklus?
In Scrum werden diese Zyklen als 'Sprints' bezeichnet. Am Anfang jedes Zyklus steht ein Planungstreffen. Hier entscheidet das Team welche Aufgaben es sich in den kommenden zwei Wochen vornehmen wird. Es betrachtet die priorisierte Aufgabenliste und notiert zumeist einzelne Aufgaben auf Haftnotizen, die auf einer Wandfläche angebracht werden. Nun wird beschlossen, wie viele dieser Einzelschritte innerhalb der nächsten zwei Wochen bewältigt werden können.
Am Ende des Sprints trifft sich das Team erneut und betrachtet die Ergebnisse seiner Zusammenarbeit: Wie viele der Haftnotizen wurden tatsächlich abgearbeitet? War man zu ehrgeizig und hat nicht alles geschafft? Hätte man sogar mehr erledigen können? Entscheidend ist, dass ein Gespür für das eigene Vermögen, die eigene Geschwindigkeit erwächst.
Nachdem die Ergebnisse vorgestellt wurden - und hier kommen wieder Ohnos Ideen i