image

image

Tobias Mayer ist ein langjähriger Bürger der Agilen Welt, ein Schriftsteller, Mentor, Lehrer und Vortragender. Er hat sich der Befreiung der Arbeitswelt verschrieben und darüber denkt er oft nach, äußert sich dazu, publiziert und bietet Workshops zu Graswurzelinitiativen an. Tobias schaut auf eine abwechslungsreiche und wilde Vergangenheit zurück, inklusive vieler Jahre als Softwareentwickler und Tester. Er ist kontinuierlich auf der Suche nach einem integrierten Leben.

image

Olaf Lewitz hat sich vom Programmierer zum Chef zum Berater zum Coach entwickelt und dann den Trust Artist als seine Berufung entdeckt. Mit Christine Neidhardt gründete er die TrustTemenos Leadership Academy. Sie helfen Führungskräften, für sich selbst das zu entdecken und zu erleben, was sie für andere schaffen möchten. In dieser Arbeit mit sich wandelnden menschlichen Systemen integriert Olaf seine Leidenschaften: Freiheit, geteilte Macht und Respekt für menschliches Drama.

image

Urs Reupke ist Berater, Trainer und Coach für Agilität bei it-agile. In fast 15 Jahren Erfahrung mit Agilität hat er gelernt, dass Miteinander, Prozess und Technik Hand in Hand gehen müssen, damit das Ergebnis stimmt.

Heute gibt er diese Erfahrung weiter und hilft Unternehmen aller Größen, elegante Lösungen für ihre strukturellen Probleme zu finden.

image

Sandra Reupke-Sieroux ist seit 2010 agile Beraterin bei it-agile. Ende der 90er wurde sie während ihres Mathematikstudiums mit dem »agilen Virus« infiziert. Seither hat sie begeistert in zahlreichen kleinen und großen Projekten agile Entwicklungspraktiken und -werte gelebt und weitergetragen. Heute liegt ihr Hauptaugenmerk auf agiler Organisationsentwicklung.

image

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Tobias Mayer · Olaf Lewitz · Urs Reupke ·
Sandra Reupke-Sieroux

The People’s Scrum

Revolutionäre Ideen für den agilen Wandel

2., überarbeitete Auflage

image

Tobias Mayer

work@tobiasmayer.uk

Lektorat: Miriam Metsch, Christa Preisendanz

Bibliografische Information der Deutschen Nationalbibliothek

ISBN:

2., überarbeitete Auflage 2018

Die 1. Auflage der deutschen Übersetzung ist 2015 unter dem Titel »Des Volkes Scrum: Revolutionäre Ideen zur Agilen Umgestaltung« bei Dymaxicon als Kindle Edition erschienen.

Autorisierte Übersetzung der amerikanischen Originalausgabe mit dem Titel »The People’s Scrum« von Tobias Mayer, erschienen bei Dymaxicon, San Francisco, CA, ISBN 978-1-937965-15-0, www.dymaxicon.com, Copyright © 2013

Authorized translation from the American language edition, entitled »The People’s Scrum« by Tobias Mayer, published by Dymaxicon, San Francisco, CA, ISBN 978-1-937965-15-0, www.dymaxicon.com, Copyright © 2013.

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Scrum ist anstrengend und befreiend

  1. Produkte sind heute erfolgreich, wenn sie begeistern. Häufiges, direktes Feedback macht das einfacher. Mit Scrum entwickeln wir Produkte in kleinen Schritten.
  2. Scrum stellt die Menschen und ihre Bedürfnisse in den Mittelpunkt. Scrum wirkt gegen Ausbeutung und Unterdrückung. Es befreit uns. Mit Scrum kommunizieren wir auf Augenhöhe.
  3. Wir arbeiten in Scrum mit funktionsübergreifenden Teams, die sich selbst organisieren. Mit Vertrauen und Verbindlichkeit fördern wir jeden und jede und nutzen ihre Beiträge bestmöglich.
  4. Wir entwickeln unser Produkt in kleinen, wertvollen Portionen, die wir direkt ausliefern. Dadurch können wir es uns leisten, zu experimentieren, und erfahren regelmäßig mehr über die Bedürfnisse aller. So maximieren wir den Ertrag und den Spaß bei der Arbeit.
  5. Scrum nutzt bewährte Praktiken, inspiriert von Lean Thinking und empirischer Prozesskontrolle. Es passt zu unserer immer ungewisseren und schwerer vorhersehbaren Welt; es eignet sich für riskante, komplexe, kleine und große Vorhaben.
  6. Scrum erlaubt uns zu erkennen, wo in unserer Organisation noch Verschwendung, Politik1, Unterdrückung und andere Mängel die Entwicklung hemmen. Wir haben die Möglichkeit, diese Unzulänglichkeiten zu beheben, um die beste Organisation zu werden, die wir sein wollen.
  7. Scrum ist so transparent und befreiend, dass es viele Organisationen in der Anwendung anstrengt. Diese Anstrengung auszuhalten und sich durch sie zu verbessern, ist Erfolg versprechender, als Scrum anzupassen und nur teilweise einzusetzen.
  8. Scrum ist ein Katalysator des Wandels, keine Lösung. Als Menschen können wir uns nur selbst ändern, nicht andere. Unser Wandel lädt andere zum Wandel ein. In hierarchischen Organisationen wird der Wandel schneller und leichter sein, wenn er von oben gewollt und geführt ist.
  9. Iterative und inkrementelle Entwicklung lädt uns ein, schwierige Dinge einfacher zu gestalten, weil wir sie häufiger tun. Damit ändert sich die technische Umsetzung auf der einen und der Dialog mit Kunden und Anwendern auf der anderen Seite.
  10. Scrum ermuntert uns, weniger auf Vorhersagen zu vertrauen, sondern mutig zu experimentieren. Es lässt uns unseren Kontext aktiv beeinflussen, anstatt zu reagieren. Die leidenschaftliche Beteiligung aller Menschen an der Entwicklung der Produkte, der Organisation und ihrer Umgebung wird dabei gefördert.
  11. Scrum hilft uns, Gewohnheiten infrage zu stellen. Es befreit uns von Zwängen und schafft so neue Wahlmöglichkeiten. So können wir immer neue Optionen zur Wertschöpfung erkennen und nutzen.
  12. Loslassen des Bewährten erfordert Anerkennung. Reflektieren und Experimentieren bedürfen der Verzeihung. Scrum fördert und fordert eine Kultur der Wertschätzung und des Vertrauens. Wir behandeln Menschen als Erwachsene.

Inspiriert von Ken Schwaber, Scrum is hard and disruptive, 20062

Geleitwort

Zuerst habe ich Tobias als jemanden wahrgenommen, der alles anders macht. Der sich nicht um Konventionen schert. Der hinterfragt. Den der große Ken Schwaber hinausgeworfen hat, weil er es gewagt hat, über die Weiterentwicklung von Scrum zu reden. Er hat damals Scrum 2.0 gesagt. Später wurde er – wie man hörte nach einem Vieraugengespräch – wieder in Gnaden aufgenommen.

Dann war er Creative Director im Board der Scrum Alliance, nachdem Ken Schwaber die Scrum Alliance im Streit verlassen hatte – dummerweise war er gleichzeitig für den zentralen Prozess zuständig: wie man akkreditierter Scrum-Trainer wird und bleibt. Das politischste und umstrittenste Thema der Scrum Alliance überhaupt. Das funktionierte nicht und Tobias ging wieder.

Inzwischen ist er wieder in der Scrum Alliance als Trainer aktiv. Scrum und die Agilität lassen ihn offensichtlich nicht los. Wie erwartet eckt er wieder an: Seine Ansichten kreisen um Menschen, nicht um Prozesse. Er stemmt sich gegen Standardisierung, bleibt ein Advokat der Kreativität und wehrt sich vehement dagegen, die Verbindung mit den agilen Werten, seinem Wertesystem, zu verlieren.

Ich bin fest davon überzeugt, dass das ein Resultat seiner Erfahrungen ist: Wer einmal als Sozialarbeiter die dunkle Seite gesehen hat, der kann nicht mehr Menschen als Ressourcen abstrahieren. Und wer im Theater gesehen hat, wie Kreativität entsteht, ist viel sensibler für die Versuchung, den Entwicklungsprozess zu taylorisieren.

Tobias hat für mich den Code geknackt, wie man Scrum, das für mich ursprünglich ein für Anfänger kompatibles Paket von Praktiken war, auf einer höheren Ebene beschreibt – auf eine höhere Ebene hebt. Für ihn ist Scrum nicht einfach ein Werkzeug oder gar ein Prozess, sondern fast eine Lebensweise und gleichzeitig verliert er nie die Verbindung zu der pragmatischen, nützlichen Seite von Scrum.

Ich hatte das Glück, eine Konferenz-Session von Tobias mitzuerleben. Er redete über die Seele von Scrum (im Wesentlichen der Inhalt des gleichnamigen Kapitels in diesem Buch). Er schafft es darin, gleichzeitig den Kern der Abläufe zu erklären, auf ihre Wurzeln zu verweisen, die Abläufe mit Werten zu verknüpfen und dabei auch nicht einmal belehrend zu werden. Ich versuche mir das in meinen Scrum-Trainings immer als Vorbild zu nehmen, diesem Ideal näherzukommen. Die Präzision und Leichtigkeit von Tobias werde ich aber niemals erreichen.

Das sind die beiden Seiten, die für mich dieses Buch so wunderbar machen. Tobias scheint dabei als Mensch durch, der Erfolg hat und dabei niemals die Schere in seinen Kopf lässt, sondern immer seine menschliche Sicht behält. Auf der anderen Seite schafft er es, spielerisch, fast nebenbei die zentralen Prinzipien und Zusammenhänge so präzise zu erklären, dass man es kaum bemerkt.

Krishan Mathis
München, August 2017

Vorwort

Olafs Geschichte

Ich lernte Tobias Mayer 2009 beim Scrum Gathering in München kennen; er hatte gerade die Position als Creative Director der Scrum Alliance übernommen. Ich hoffte, dass er diese Organisation erneuert, die mir schon damals zu sehr auf Gewinn bedacht war. Tobias inspirierte uns in den Pausen mit lehrreichen interaktiven und körperlichen Übungen. Er war ein Querdenker, unerschütterlich in seinem Fokus auf die Menschen. Ich bewunderte seinen Mut, zu polarisieren, und die Offenheit, mit der er Missstände ansprach, die seiner Vision von Freiheit und Menschlichkeit im Wege standen.

Mit neun Zeitzonen zwischen uns trafen wir uns nur wenige Male wieder. Twitter ermöglichte uns, in Kontakt zu bleiben. Wir wurden Freunde. Wir rieben uns an ähnlichen Dingen und teilten viele Ziele und Wünsche. Sein Beispiel gab mir Kraft, vom Unwillen zum Widerstand und weiter zur Führung zu kommen, auf meine Fähigkeiten und Instinkte zu vertrauen und nicht nachzugeben.

Als er 2013 The People’s Scrum veröffentlichte, schrieb er mir: »Ich möchte, dass mein Buch ins Deutsche übertragen wird. Ich kann mir dafür keinen Besseren vorstellen als Dich.« Heute, vier Jahre später, kann ich diese Aussage annehmen, ehrliche Dankbarkeit und Stolz empfinden. Damals konnte ich dieses Kompliment nicht an mich heranlassen … Aber natürlich fühlte ich mich geehrt und habe mich der Herausforderung gestellt.

Wie Tobias bin ich ein geborener Agilist. Ich musste nie Software nach einer festgelegten Spezifikation schreiben und habe nie in einem Projekt gearbeitet, in dem andere vorher die ganze Arbeit im Detail geplant hatten. Ich habe von »Software Engineering«1 immer nur gelesen. Als Kent Beck und andere Ende der Neunziger auf dem C2-Wiki XP2 entwickelten, atmeten meine Kollegen und ich erleichtert auf: »Endlich schreibt mal jemand auf, wie man wirklich Software entwickelt!«

Im Jahr 2000 wurde ich Entwicklungsleiter in Hamburg. Meine Kollegen hatten zur Begrüßung eine Leiter neben meinen Stuhl gestellt – ich war verunsichert. Ich hatte viel Leidenschaft, aber keine Lust, jemandem zu sagen, was er machen soll. Ich hatte auch keine Ahnung wie. Mein Vater hat mir eine rebellische Ader vererbt, Regeln und Anweisungen inspirieren mich zum Widerstand. Und jetzt sollte ich jemandem etwas vorschreiben?

Ich fand XP toll und führte es als Methode ein. Mein Boss fand das seltsam, aber er vertraute uns. Wir waren erfolgreich, bis die Investoren in einem politischen Ränkespiel den Boss durch zwei Jungspunde ersetzten und ein paar Monate später ihr Geld aus der Firma nahmen. Einer der Jungspunde war ich. Dreißig, Boss und keine Ahnung, wie das geht. Ein großes Herz, Mut und eine Gewissheit: Du darfst niemanden fragen, denn du bist ja der Boss. Schwäche zeigen ist nicht.

Ich habe eine Menge Empathie für Manager.

Mein nächster Boss war sehr ehrlich: »Ich kann Sie nur einstellen, wenn Sie im ersten Jahr mehr Geld einbringen, als Sie mich kosten. Sie müssen als Berater zum Kunden gehen.« Diese Erfahrung hat mich der Illusion beraubt, ich sei introvertiert. Sie hat mir auch bewusst gemacht, dass ich etwas ändern kann, dass die meisten Menschen sich das nicht zutrauen. Und dass Agilität wirklich funktioniert und Menschen befreien kann.

Ich lernte 2009 in München nicht nur Tobias kennen, sondern auch Mike Sutton, Rachel Davies, Andrea Tomasini, … Ich war unter Gleichgesinnten. Ich fand Freunde. Ich ging in der agilen Community auf. I had found my tribe3.

Ich wurde neugierig auf Coaching. Ich vernetzte mich und lernte, wurde neugieriger und lernte mehr. Ich gewann Klarheit über meine Berufung: Menschen Vertrauen schenken. Vertrauen in sich selbst, in andere, um neue Möglichkeiten zu erkennen, die Freiheit zu wagen, die Welt mit anderen Augen zu sehen. Ich fand meinen Weg als Trust Artist.

Tobias’ Angebot hat mich geehrt, riesig gefreut und völlig überfordert. Ich hatte mich gerade selbstständig gemacht. Die Übersetzung kam schleppend voran. Im Februar 2014 traf ich Alan Cyment bei der Play4Agile4. Ein Rebell und Menschenfreund wie Tobias und ich und der Autor der spanischen Version dieses Buches. Er inspirierte mich zu tun, was ich dauernd anderen empfehle: Ich bat um Hilfe! Sandra und Urs waren spontan interessiert, Alan gab uns ein paar Tipps … Innerhalb der ersten Woche dieser Teamarbeit stieg die Anzahl übersetzter Essays von 9 auf über 20: Ich hatte mehr geschafft als in dem Dreivierteljahr zuvor. So sehr kann ein Team die Produktivität steigern. :-)

Wir lernten, wie wir uns gut ergänzen, wer welche Stärken und Schwächen hat und wie wir diese ausgleichen. Den größten Einfluss auf meine Produktivität hatte die simple Tatsache, dass ich nicht mehr allein war: Ich wusste, jemand liest, was ich schreibe, jemand gibt Feedback. Unsere Ansichten waren häufig komplementär, und wir haben vielfach gemerkt, dass Sandra und Urs meine Formulierungen schlanker und klarer gemacht haben – wie auch umgekehrt. Wir haben um viele Worte regelrecht gerungen. Das war herausfordernd und sehr effektiv.

Für uns alle war diese Übersetzung ein nebenberufliches Projekt, das ausschließlich online stattfand. Wir haben uns in dem halben Jahr nicht persönlich gesehen. So gab es in unserer Zusammenarbeit intensive und ruhige Phasen. Die Verbindung ist in dieser Zeit nie abgerissen. Das war toll.

Seit 2009 habe ich in der agilen Community ein Zuhause gefunden. Wie in jeder Gruppe von engagierten Menschen mangelt es auch bei uns nicht an Reibung. Wir diskutieren hitzig über richtig und falsch, Gut und Böse. Meistens lernen wir dabei. Manche von uns sind gut darin, Widersprüche zu konsolidieren, manche machen uns darauf aufmerksam und polarisieren. Tobias ist international als Provokateur bekannt, wegen seines Blogs »Agile Anarchy« und auch aufgrund seiner Konflikte mit der Scrum Alliance, die er im nächsten Kapitel in seiner Geschichte beschreibt. Boris Gloger polarisiert in der deutschen Scrum Community ebenso, das ist mir schon 2009 in München aufgefallen. So war es kein Zufall, dass Tobias sich ein Nachwort von Boris für dieses Buch wünschte. Sein Wunsch führte zu intensiven Diskussionen in unserem Team und mit anderen Menschen in der Community. Im Sinne der Botschaft dieses Buches, von dem, was uns vor allem am Herzen liegt, haben wir uns entschieden, ein Zeichen zu setzen. Wir wollen das Schisma überwinden. Ich bin froh und stolz, dass Boris Tobias’ und unserem Wunsch entsprochen hat, dieses Buch und Tobias’ Wirken zu kommentieren.

Sein Nachwort hat mich tief berührt.

Nun sind drei Jahre vergangen und wir stehen kurz vor der Veröffentlichung der zweiten Auflage, die du nun liest. Krishan Mathis ist einer meiner Gefährten in der Auseinandersetzung mit Tobias’ Arbeit – insbesondere diesem Buch – gewesen. Wir haben Workshops zu »The People’s Scrum« für Konferenzen entwickelt.

Es freut mich besonders, dass Krishan ein Geleitwort für diese neue Auflage geschrieben hat, in dem Tobias’ Worte und sein Wirken eine ganz persönliche Würdigung bekommen. Seine Stimme fügt diesem Buch eine andere Perspektive hinzu, für die ich dankbar bin und stolz, dass sie gleich am Anfang steht.

Danke Boris, danke Krishan und danke Tobias!

Und danke Urs und Sandra …

Dir viel Freude und Neugier beim Lesen.

image

Seit dem Finalisieren dieses Textes für die erste Veröffentlichung auf Kindle – Dank an Dymaxicon für den Mut, einen Text in fremder Sprache und einem fremden Markt zu veröffentlichen – ist viel passiert.

Ich habe meinen Weg als Trust Artist fortgesetzt, viel Bestätigung erfahren und tatsächlich gelernt, wie Vertrauen funktioniert, wie man es aufbaut und fördert. Vieles davon findet sich in diesem Buch: Geschichten vom Scheitern, Fallen und wieder Aufstehen, mit Emotionen und Spannungen, Kontroversen und Einigkeit … Geschichten von Menschen eben, die uns zusammenbringen und Nähe und Geborgenheit geben.

Und nur darauf kommt es an: auf die Menschen und darauf, Räume zu schaffen, in denen wir sein und wachsen können. Scrum kann man benutzen, um solche Räume zu bauen. Das ist der Punkt in Tobias’ Buch, in unserem Buch.

Schaffen von Räumen – das ist heute der Fokus meiner Arbeit. Zusammen mit Christine Neidhardt habe ich vor zwei Jahren die TrustTemenos Leadership Academy gestartet – ein Programm für Führungskräfte, in dem sie selbst entdecken und erleben können, was sie in ihrem Umfeld schaffen möchten.

Ich freue mich sehr auf die neue Ausgabe im dpunkt.verlag und darüber, dass unser Werk nun so einem größeren Publikum zugänglich wird. Christa Preisendanz hat uns nicht nur mit ihrem Enthusiasmus vom dpunkt.verlag überzeugt, sondern auch mit großer Sorgfalt und viel Liebe zum Detail diese Veröffentlichung in einem Rekordtempo möglich gemacht. Danke dafür!

Qapla’!

Olaf Lewitz
Berlin, Juli 2017

Tobias’ Geschichte

Ich habe spät in meinem Leben zur Softwareentwicklung gefunden. Im Alter von 35 Jahren benutzte ich das erste Mal einen Computer – und auch nur, weil ich musste. Ich hatte einen Job als Lebenskompetenztrainer für Jugendliche auf Bewährung angenommen. Ich musste Lehrpläne entwickeln, Fortschritte dokumentieren und Berichte schreiben. Entscheidend waren Tabellenkalkulation und Textverarbeitung.

Computer interessierten mich damals nicht, im Gegenteil, sie machten mir Angst. Ich erkannte ihren Wert nicht, vermied sogar den Kontakt, wo ich nur konnte. Aber die Notwendigkeit siegte. Nachdem ich jedoch die Grundlagen verstanden hatte, war ich fasziniert.

Ich wollte erforschen, was unter der Oberfläche war, mir die Hände mit Nullen und Einsen schmutzig machen, mit Maschinencode. Ich wollte verstehen, wie dieses Ding funktioniert und was ich machen könnte, um es zu verändern. Basteln macht mich glücklich!

Ich schrieb mein erstes Programm in DOS QBasic5, und sogar mit einer so groben Sprache stellte ich – zu meiner Überraschung – fest, dass Programmieren nur zu zwanzig Prozent aus Mathematik und Logik besteht. Der Rest ist reine Poesie. Ich hing am Haken. Ein Jahr später schrieb ich mich an der Londoner South Bank University ein, schaffte 1999 meinen Bachelorabschluss und begann eine neue Laufbahn.

Mein Werdegang hatte mich zum Bau, zum Grafikdesign und zur Bühnentechnik geführt. Später war ich Trainer und Vermittler im Sozialbereich und im Bewährungssystem; dabei habe ich mit verschiedenen benachteiligten Gruppen und Individuen an persönlicher Selbstverwirklichung gearbeitet. Diese Arbeit war so weit wie irgend vorstellbar entfernt von der Softwareentwicklung und doch hat keine Erfahrung mir mehr genützt in der Welt der agilen Coaches und Berater.

Entrechtete Teenager und Softwareentwickler in großen, beklemmenden Organisationen – da gibt es mehr Gemeinsamkeiten als Unterschiede. Beide Gruppen werden zum Schweigen gebracht; beide haben viel zu erzählen. Der agile Berater gibt der schweigenden Mehrheit eine Stimme, setzt den kreativen, manchmal anarchischen Geist frei und geht dann beiseite.

Während meines Studiums konnte ich ein Jahr lang forschen, bevor mein Abschluss nahte. Ich spürte früh, dass ein starrer Prozess für die Steuerung eines kreativen Vorhabens ein Blindgänger ist und nur Schmerzen verursacht. Ich denke mir die Dinge lieber im Laufe der Arbeit aus. Meine Forschung kreiste daher um Softwareprozesse: Ich untersuchte, was wir gewonnen haben und was verloren ging, während die Softwarewelt sich von einer anarchischen Hackerkultur zu einer kontrollierten Firmenkultur wandelte. Ich stieß schnell auf Kent Becks frühe Arbeiten zu Extreme Programming (XP). In ihnen entdeckte ich die menschlichen Werte, die bei den ursprünglichen Hackern der 60er- und 70er-Jahre so präsent waren – nur mit mehr Disziplin. Ich war fasziniert. Es sollten noch einige Jahre vergehen, bevor ich diese Theorie in die Praxis umsetzen konnte, aber die Saat der Agilität war gesät. Becks Arbeit war leichtgewichtig, auf den Menschen fokussiert – und kontrovers. Sie hat viele Akademiker und Praktiker schockiert, die immer noch glaubten, dass wir mehr Prozess brauchen und nicht weniger, um die Ergebnisse zu kontrollieren. Ich begann, eine Idee, über die ich selbst wenig wusste, gegen erfahrene Veteranen des Fachs zu verteidigen: Intuitiv spürte ich, dass Beck recht hatte und dass der Rest unserer Branche mehr und mehr falsch lag.

Agil entdecken

Mein Abschluss 1999 fiel mit dem Umzug meiner Familie von London nach Palo Alto zusammen. Es war purer Zufall, dass die Heimat meiner damaligen Frau im Herzen der Computerindustrie lag. Wir zogen der Familie wegen dahin, nicht wegen der Arbeit, aber ich fand rasch einen Job bei einem kleinen Start-up-Unternehmen. Es baute Werkzeuge, um Websites zu testen; Testen und Messen waren Schwerpunkte meines Studiums gewesen. Das passte also ganz gut.

Da ich zur Jahrhundertwende in die Softwareentwicklung kam, blieb mir viel Unsinn erspart, durch den sich die meisten Entwickler meiner Generation in den 80ern und 90ern quälen mussten: Ich trug keine Anzüge bei der Arbeit; es gab keine starren Top-down-Prozesse; niemand glaubte mehr, Entwickler seien Rädchen im großen Business-Getriebe, verfügbar und austauschbar durch mechanische Codegeneratoren oder billige Dritte-WeltArbeit.

Die agile Bewegung begann sich zu rühren: Das erste Scrum-Patterns-Paper war 1993 veröffentlicht worden und Tob Gilbs evolutionäres Projektmanagement (Evo) gab es schon seit mehr als zehn Jahren, auch wenn es selten angewandt wurde. Die Scientific-Management-Modelle aber waren immer noch nicht aus der Mode. Unsere Branche hatte sie unerklärlicherweise aus Frederick W. Taylors Arbeit über Effizienz übernommen, die die Industrie des frühen 20. Jahrhunderts geprägt hat. Diese Modelle wurden jedoch zunehmend untergraben, da die Internetwelt uns zu immer höherer Geschwindigkeit herausforderte.

Silicon Valley spielte in den späten 90ern verrückt: Start-ups entstanden täglich und starben genauso schnell, Menschen wurden über Nacht Millionäre, nur um alles ein paar Monate später wieder zu verlieren. Die Firma, für die ich arbeitete, war ein chaotischer Zirkus voller Mikromanagement. Ich plagte mich damit, einige gute Entwicklungs- und Testpraktiken einzuführen – aber den Kunden bei Laune zu halten war wichtiger als alle Sorgen über Qualität, Nachhaltigkeit oder die Gesundheit der Mitarbeiter. Ironischerweise haben wir Werkzeuge gebaut, um anderen zu helfen, die Qualität zu verbessern. Aber wer testet die Testtools?

Ich lernte viel über Testen in dieser Zeit. Unser Geschäft führte mich regelmäßig auf die Quality-Week-Konferenzen in Europa und den USA. Dort traf ich Lisa Crispin und Tip House, die mir »Extremes Testen« vorstellten. Das Konzept faszinierte und begeisterte mich, belebte mein Interesse an Extreme Programming wieder und brachte mich zurück zu Kent Beck. Ich kaufte sein neuestes Buch, aber im folgenden Jahr setzte es auf meinem Regal nur Staub an – in meinen wenigen freien Momenten zog ich Schlaf dem Lesen vor.

Der Firma, für die ich arbeitete, ging Ende 2001 das Geld aus – sie zahlte keine Gehälter mehr und kollabierte 2002; ich war zeitweise arbeitslos – und pleite. Nach einigen Monaten auf dem Bau wurde mir bei Yahoo! Eine Position auf Zeit angeboten, die später zu einer Festanstellung wurde.

Immer noch fasziniert vom XP-Ansatz, nahm ich mir jetzt die Zeit für Becks Buch, und wir probierten die Ideen in unserer Gruppe aus. Wir konnten nicht für uns beanspruchen, ein XP-Team gewesen zu sein, aber wir haben in Paaren programmiert, Unit Tests geschrieben, regelmäßig refaktoriert und kontinuierlich integriert. In der »agile-testing«-Mailingliste, die Lisa Crispin und Brian Marick 2000 gestartet hatten, lernte ich bessere Methoden kennen, Software früh im Entwicklungsprozess zu testen. Wir entfernten die Barriere zwischen Entwicklung und Qualitätssicherung und begannen als gemeinsames Team zu arbeiten. Wir verbrachten große Teile des Tages in Paaren aus Entwicklern und Testern. Das war etwas Echtes. Es hatte Bedeutung. Wir hatten Spaß an unserer Arbeit und wussten: Wir hatten noch einen weiten Weg vor uns. Allen Bemühungen unserer kleinen Gruppe zum Trotz waren wir noch immer umgeben von einer Kultur, die in ihren herkömmlichen Vorstellungen von Management gefangen war. Mal für Mal bestürzten und frustrierten mich die plumpen Prozesse, die endlosen Besprechungen, der Mangel an Zusammenarbeit und die klaffende Lücke zwischen Entwicklern und Kunden.

2003 wurde ich in eine Führungsposition befördert und bekam Gelegenheit, diese Lektionen im größeren Kreis zu teilen. Ich leitete ein Team von zwölf Personen. Mein eigener Chef erlaubte mir, weiter in die Agilität einzutauchen, und sehr bald entdeckte ich Scrum. Mit seinem leichtgewichtigen, teamzentrierten Ansatz bot Scrum die erfrischende Möglichkeit, die Arbeit auf intuitive Weise zu organisieren. Das Konzept der selbstorganisierten Teams passte sehr gut zu meiner früheren Arbeit im Jugend- und Sozialbereich.

Zu Beginn des Jahres 2004 las ich die beiden Bücher über Scrum, die damals schon erschienen waren, und nahm an Ken Schwabers und Kert Petersons Training zum Certified Scrum Master (CSM) teil. Die folgenden sechs Monate praktizierte unser Team Undercover-Scrum. Wir sammelten detaillierte Metriken über Fehlerzahlen, Durchlaufzeiten, Meilensteine, Ausfallzeiten und andere interessante Werte und verglichen die Zahlen mit unseren früheren Projekten. Wir konnten mehr als 500 Prozent Verbesserung in Qualität und Time-to-Market vorweisen! Es war bemerkenswert.

Im Januar 2005, nachdem die bekannten Agilisten Ken Schwaber, Jeff Sutherland und Mike Cohn Vorträge bei uns gehalten hatten, konnte ich die Produktorganisation bei Yahoo! überzeugen, ein Scrum-Pilotprojekt mit fünf Gruppen zu starten. Ich änderte zu diesem Zeitpunkt meine Rolle und wurde Teil des neuen Agile Process Team