agile projekte mit scrum, xp und kanban...agile projekte mit scrum, xp und kanban im unternehmen...

23

Upload: others

Post on 30-Jun-2020

12 views

Category:

Documents


0 download

TRANSCRIPT

Agile Projekte mit Scrum, XP und Kanban im Unternehmen durchführen

Dipl.-Inform. Henning Wolf ist Geschäftsführer und Senior-Berater bei der it-agile GmbH in Hamburg. Er arbeitet in agilen Projekten und begleitet sie seit 1999. Neben agilen Methoden und Vertragsmodellen gehören agiles Projektmanagement und Controlling, Aufwandsschät-zungen und agile Organisationen zu seinen Arbeitsschwerpunkten. Im Rahmen seiner Beratertätigkeit veröffentlicht er Artikel und hält Vor-träge und Schulungen zu diesen und weiteren Themen.

Henning Wolf (Hrsg.)

Agile Projekte mit Scrum, XP und Kanban im Unternehmen durchführen

Erfahrungsberichte aus der Praxis

Henning Wolf [email protected]

Lektorat: Christa Preisendanz Copy-Editing: Ursula Zimpfer, Herrenberg Herstellung: Birgit Bäuerlein Umschlaggestaltung: Helmut Kraus, www.exclam.de Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN: Buch 978-3-89864-752-6PDF 978-3-86491-064-7ePub 978-3-86491-065-4

1. Auflage 2012 Copyright © 2012 dpunkt.verlag GmbH Ringstraße 19 B 69115 Heidelberg

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

v

Vorwort

Warum dieses Buch?

Die Idee zu diesem Buch entstand vor allem aus einem Grund: Ich wollte ein sol-ches Buch gerne lesen, und ich wollte es gerne empfehlen können, um Interessen-ten an agiler Softwareentwicklung das Spektrum gelebter Agilität im tatsäch-lichen täglichen Einsatz zu zeigen. Denn allzu oft höre ich, dass man agile Softwareentwicklung so wie im Lehrbuch ja nicht in der Praxis umsetzen könnte. Da ist zwar etwas dran, aber anders, als die meisten vermuten. Es hat nämlich mehr damit zu tun, dass agile Methoden systematisch unterspezifiziert sind und lokale Erweiterungen und Anpassungen an die Organisation vorgenommen wer-den müssen, in denen agile Projekte oder agile Produktentwicklung eingebettet stattfindet. Es hat nichts damit zu tun, dass agile Methoden etwas fordern, was Organisationen nicht leisten könnten (wie Commitments, Fokus, agile Arbeitsbe-dingungen, feste Teams, priorisierte Anforderungen, häufige Auslieferungen, Selbstorganisation etc.).

Das Buch selbst kam vor allem dadurch zustande, dass so viele Kolleginnen und Kollegen aus der agilen Gemeinde in Deutschland bereit waren, ihre Erfah-rungen beizutragen. Vielen herzlichen Dank dafür.

Danksagungen

Mein Hauptdank als Herausgeber gilt den Autoren, die hier in alphabetischer Reihenfolge aufgeführt sind:

■ Markus Andrezak von mobile.de habe ich als einen unserer Kunden kennen-gelernt. Er ist aber nicht mehr nur ein Kunde von uns, sondern ein Freund. Er ist ein Veränderer mit Leidenschaft und es macht Spaß, mit ihm Ideen zu reflektieren und Situationen zu analysieren.

■ Alex Bepple war schon früher einmal ein Kollege von mir und ist es jetzt zum Glück bei it-agile wieder. Er ist ein sehr intelligenter analytisch denkender Coach und ein sehr überzeugender Berater. Obendrein schätze ich es auch,

Vorwortvi

dass er nicht genug Zeit zum Golfen hat, um mich auf dem Platz in Grund und Boden zu spielen.

■ Jutta Eckstein ist eines der Urgesteine der deutschen agilen Szene. Ich kenne Jutta von vielen Konferenzen, auf denen wir uns begegnet sind. Ich bin sehr froh, dass Jutta ihre umfangreichen Erfahrungen in Vorträgen und Büchern – so auch in diesem Buch – mit uns teilt.

■ Sven Günther ist ein Kollege bei it-agile, der wie die meisten von uns einen starken softwaretechnischen Hintergrund hat. Er besitzt viel Programmier-erfahrung und hat auch als Softwarearchitekt gearbeitet. Wenn er nicht agil berät, dann programmiert er iPhone-Apps, eine davon auch mit mir gemein-sam: eine App für den geneigten Agilisten – die Timebox-App.

■ Holger Koschek und ich sind uns beim Informatikstudium begegnet. Holger ist ein sehr sympathischer Zeitgenosse und ein guter Erzähler. Schön, wenn einer nicht nur meistens Recht hat, sondern es auch noch so erzählen und berichten kann, dass es Spaß macht.

■ Andreas Leidig habe ich auf zahlreichen XP Days Germany kennen- und schätzen gelernt (auch dank seines Humors und trotz oder wegen seiner manchmal sehr kritischen direkten Art).

■ André Neubauer arbeitet bei ImmobilienScout24 und wurde mir als Autor für einen Projektbericht empfohlen, worüber ich sehr froh bin. Wir teilen nicht nur die Leidenschaft für Agilität, sondern auch den Autogeschmack.

■ Christiane Philipps habe ich erst 2010 auf den XP Days Germany in Ham-burg persönlich kennengelernt. Wir haben beide ein pragmatisches Verständ-nis von Agilität (ohne die dahinterliegenden Werte zu kompromittieren). Mir gefällt gerade aus ihrer Managementperspektive ihr Verständnis für die rich-tige technische Qualität als Voraussetzung für die schnelle Umsetzung neuer Features.

■ Susanne Reppin bin ich erst bei der Arbeit an diesem Buch begegnet. Ich schätze sie sehr als eine Agilistin, die immer auch das Wohl der Teams und das des Unternehmens, in dem die Teams arbeiten, im Auge hat.

■ Sven Röpstorff kenne ich von den XP Days Germany und dem Hamburger Scrumtisch. Er ist ein überzeugter Agilist und ein gut reflektierender Coach.

■ Dr. Arne Roock ist einer meiner besten Freunde und unser Prokurist bei it-agile. Wir haben ihm dort erst Agilität näher gebracht, und weil er zum einen so intelligent und zum anderen so konsequent ist, nervt er uns seitdem im posi-tiven Sinne, dass wir auch immer schön nach agilen Grundsätzen handeln.

■ Stefan Roock und ich waren gemeinsam im Kindergarten, wir haben zusam-men Abitur gemacht, zusammen Informatik studiert und gemeinsam über eXtreme Programming Agilität für uns entdeckt. Unser Feuer brannte dafür so sehr, dass wir zusammen mit anderen 2005 it-agile gegründet haben. Ste-

viiDanksagungen

fan ist ein sehr guter Freund und ich bin froh, dass ich seine konzeptionelle Stärke in Diskussionen erleben und anzapfen darf.

■ Bernd Schiffer ist einer meiner Kollegen bei it-agile und ein sehr konsequenter Verfechter in Sachen Agilität. Ich schätze dabei besonders seine Diskussions-stärke und Überzeugungskraft.

Martin Heider gebührt der Dank als einzigem Nicht-Autor, der ein Review zu einem Projektbericht geschrieben hat. Ansonsten haben die Autoren in agiler Manier mit Feedback nicht gespart und so wechselseitig ihre Berichte verbessert. Auch hierfür noch einmal herzlichen Dank.

Ich möchte mich aber auch beim dpunkt.verlag und namentlich bei unserer Lektorin Christa Preisendanz bedanken, die mit ihrer beharrlichen Art dafür gesorgt hat, dass ich trotz anderer Buchprojekte und eines dringend verbesse-rungswürdigen Golf-Handicaps dieses Buchprojekt erfolgreich beendet habe.

Ein gewichtiger Dank geht an die Kunden und die Kollegen aller Autoren, nicht nur an diejenigen, über die hier berichtet wurde, sondern an alle, die mit uns gemeinsam Erfahrungen sammeln durften und sich mit uns auf die agile Reise gemacht haben. Manche kamen verzweifelt, manche einfach mutig, andere neu-gierig, aber alle waren sie bereit zu Veränderungen (wenn auch vielleicht nicht immer zu so weitreichenden wie wir). Beispielhaft seien hier die Kollegen von Holger Koschek, Rolf Dräther, Jo Ehm und Stefan M. Heldt, genannt.

Schließlich möchte ich mich auch bei meiner Frau Kirsten und unserer Toch-ter Anna bedanken, die viel Verständnis für den Überzeugungstäter an der Tasta-tur haben, der auch noch nach Feierabend agilen Ideen nachgeht.

Henning WolfHamburg, im August 2011

Vorwortviii

ix

Inhaltsverzeichnis

1 Einleitung 11.1 Wie Sie dieses Buch verstehen sollten . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Die Projektberichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Der Anhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Ein agiles Projekt ist kein Ponyhof 5

Holger Koschek

2.1 Der Weckruf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Das Team findet sich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Der eigentliche Auftrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Guerillagilisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5 Scrumkomplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6 Siege und Niederlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.7 Sprint-Planung I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.8 Sprint-Planung II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.9 Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.10 »Sprint« ist eine relative Geschwindigkeit . . . . . . . . . . . . . . . . . . . . 172.11 Dimensional Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.12 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.13 Pflegeanleitung für Erwartungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.14 Retrospektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.15 Meta-Retrospektive (klassisch: Fazit) . . . . . . . . . . . . . . . . . . . . . . . . 252.16 Agile Werte im Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Scrum-Einführung bei einem Internet Service Provider – 29Leben und Werk eines ScrumMastersBernd Schiffer

3.1 Das weitere Umfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 Das nähere Umfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3 Warum Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Inhaltsverzeichnisx

3.4 Ziele der Scrum-Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.5 Situation beim Coachwechsel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.6 Die Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.7 Das Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.8 Der soziale Umgang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.9 Der ScrumMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.10 Die Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.11 Multiprojektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.12 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.13 Agile Werte im Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 Scrum-Einführung bei ImmobilienScout24 47

André Neubauer

4.1 Die Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2 Die Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3 Das Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.4 Scrum 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.5 Kanban & Co. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.6 Retrospektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.7 Agile Werte im Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5 (Fast) agil in einem Großunternehmen 59

Alex Bepple · Sven Günther · Henning Wolf

5.1 Der Kunde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.2 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.3 Das neue Liefermodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.3.1 Vorphase eines Projekts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.3.2 Projektablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.4 Vorgehen bei der Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.5 Verbesserungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.6 Schwierigkeiten mit dem neuen Liefermodell . . . . . . . . . . . . . . . . . . . 675.7 Lernerfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.7.1 Lernerfahrung: Zwischenziele mit dem Management vereinbaren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.7.2 Lernerfahrung: Product Owner ermächtigen . . . . . . . . . . . . 685.7.3 Lernerfahrung: Schlechte Qualität macht langsam . . . . . . . . 695.7.4 Lernerfahrung: Radikale versus inkrementelle

Prozessinnovation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.8 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.9 Agile Werte in der Produktorganisation . . . . . . . . . . . . . . . . . . . . . . . 71

xiInhaltsverzeichnis

6 Zurück auf die agile Spur – Vom Micromanagement zu Scrum 73

Sven Röpstorff

6.1 Die Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.2 Die Mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.3 Das konkrete Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.4 Los geht’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.5 Erste Erkenntnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.6 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.7 Der erste Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.8 Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.9 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826.10 Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826.11 Sprint-Verlauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.12 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.13 Retrospektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.14 Ein paar Wochen später ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846.15 Ein paar Monate später ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.16 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.17 Agile Werte im Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7 Agile Softwareentwicklung als fundamentaler Bestandteil 87einer UnternehmensgründungAndreas Leidig

7.1 Die Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877.2 Der Zug formiert sich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.2.1 Die Vision: Wohin geht die Reise? . . . . . . . . . . . . . . . . . . . . 887.2.2 Ergebnisse des Treffens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

7.3 Vorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907.4 Die ersten Wochen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7.4.1 Es geht los: Aufstellung des Teams . . . . . . . . . . . . . . . . . . . 907.4.2 Reviews und Retrospektiven . . . . . . . . . . . . . . . . . . . . . . . . 927.4.3 Sprint-Ergebnisse und Velocity . . . . . . . . . . . . . . . . . . . . . . 927.4.4 Routine und Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937.4.5 Die Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7.5 Schwierigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957.6 Über den Tellerrand hinaus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7.6.1 Nicht funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . 977.6.2 Externe Abhängigkeiten und Kooperationen . . . . . . . . . . . . 98

7.7 Rückblickende Betrachtung und Zusammenfassung . . . . . . . . . . . . . 997.8 Agile Werte im Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Inhaltsverzeichnisxii

8 Erfolgreich im Festpreis 103

Stefan Roock

8.1 Vor dem Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038.2 Der Projektbeginn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

8.2.1 Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1048.2.2 Arbeit im Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1058.2.3 Überstunden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

8.3 Projektdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

8.3.1 Problematische Releaseplanung . . . . . . . . . . . . . . . . . . . . . 1068.3.2 Der Raum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1078.3.3 Umgang mit Hindernissen . . . . . . . . . . . . . . . . . . . . . . . . . 1078.3.4 Die Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1088.3.5 Die Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1098.3.6 Zwei neue Entwickler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

8.4 Der Projektabschluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1098.5 Agile Werte im Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

9 Kanban – so starten Systemadministratoren 113

Susanne Reppin

9.1 Der Samen »Kanban« wird gesät . . . . . . . . . . . . . . . . . . . . . . . . . . . 1139.2 Die Vorbereitung des Vorschlags für das Team . . . . . . . . . . . . . . . . 115

9.2.1 Um dieses Team geht es hier ... . . . . . . . . . . . . . . . . . . . . . . 1159.2.2 Die Rollen zur Einführung von Kanban . . . . . . . . . . . . . . . 1169.2.3 Die Werkzeugkiste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1169.2.4 Der Plan für das Treffen mit dem Team . . . . . . . . . . . . . . . 117

9.3 Der Vorschlag wird dem Team vorgestellt . . . . . . . . . . . . . . . . . . . . 1179.4 Das neue Kanban-Team startet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1219.5 Der Start des Teams – Zusammenfassung . . . . . . . . . . . . . . . . . . . . 1249.6 Unsere Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1249.7 Die Administratoren machen weiter als Kanban-Team . . . . . . . . . . 1379.8 Erkenntnis für uns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1379.9 Das Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1389.10 Das Umfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1389.11 Agile Werte im Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

xiiiInhaltsverzeichnis

10 mobile.de agil 141

Markus Andrezak

10.1 Vorher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14110.2 Der Anfang – plötzlich Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

10.2.1 Neue Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14310.2.2 Neue Lösungen – Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 14410.2.3 Outsourcing, Offshoring . . . . . . . . . . . . . . . . . . . . . . . . . . 14410.2.4 Strategische Projekte – Gears . . . . . . . . . . . . . . . . . . . . . . . 14410.2.5 Coaching-begleitete Scrum-Einführung . . . . . . . . . . . . . . . 14510.2.6 Prozess und Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14610.2.7 Koordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14610.2.8 Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14710.2.9 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

10.3 Und dann noch Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14810.4 Aber wo sind die Werte? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15110.5 Portfolio-Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15110.6 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

10.6.1 Neue Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15410.6.2 Vertrauensbasierte Prozesse . . . . . . . . . . . . . . . . . . . . . . . . 155

10.7 Die Essenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

11 Agilität in Internet-Start-ups 157

Christiane Philipps

11.1 Grundsätzliche Anmerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15711.2 Die typische Entwicklungskurve eines Start-ups . . . . . . . . . . . . . . . 15911.3 Der Ausweg aus dem Chaos: Agilität oder Wasserfall? . . . . . . . . . . 16111.4 Die Ähnlichkeiten zwischen Start-up- und agiler Kultur . . . . . . . . . 16211.5 So leicht ist es dann doch nicht – die klassischen

Start-up-Probleme mit Agilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16611.6 Wir sind agil – 16 Stunden pro Tag . . . . . . . . . . . . . . . . . . . . . . . . 16711.7 Das beliebte Problem der Doppelrollen . . . . . . . . . . . . . . . . . . . . . 16811.8 Scrum vs. Kanban – vs. XP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17011.9 Automatisiertes Testen und Refactoring . . . . . . . . . . . . . . . . . . . . . 17211.10 Sprint-Längen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17311.11 Big Bang oder Politik der kleinen Schritte? . . . . . . . . . . . . . . . . . . . 17411.12 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Inhaltsverzeichnisxiv

12 Transparenz 177

Jutta Eckstein

12.1 Feedback führt zu Transparenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17712.2 Probleme frühzeitig adressieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17912.3 Evolutionäre Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18012.4 Entwicklungsgeschwindigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18112.5 Kundenfeedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18412.6 Vertrauen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18512.7 Schlussbetrachtung: Agilität wirksam einsetzen . . . . . . . . . . . . . . . . 186

13 Agil bei it-agile: Pull in Vertrieb und Verwaltung 187

Arne Roock

13.1 Changeban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18713.2 Lernerfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18913.3 Akquise-Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Literaturverzeichnis 197

Die Autoren 201

Index 205

1

1 Einleitung

1.1 Wie Sie dieses Buch verstehen sollten

Die Idee dieses Buches ist es, dass Sie mit gewissen Vorkenntnissen durch die Pra-xisberichte Ideen erhalten, die eben weiter gehen als das, was Sie in reinen Methodenbüchern zu lesen und zu bearbeiten bekommen. Ein Buch über agile Methoden sollten Sie aber auch schon gelesen haben, denn das vorliegende Buch erklärt nicht, welche Rollen es bei Scrum gibt oder wie welche Praktik aus eXtreme Programming (XP) genau funktioniert.

In diesem Buch werden praktische Probleme und Lösungsideen mit Erfahrun-gen aus echten Projekten beschrieben. Nehmen Sie diese Ideen als eine Erweite-rung Ihres agilen Werkzeugkastens, aber bleiben Sie bitte der agilen Grundidee beim Einsatz treu: Entscheiden Sie selbst anhand Ihrer konkreten Situation und verfahren nicht nur so, weil Sie es irgendwo gelesen haben. Reflektieren Sie selbst über den Erfolg des Einsatzes und nehmen Sie ähnlich wie die Autoren hier Ihre eigenen Anpassungen vor. Nur so kommen Sie Schritt für Schritt für Ihr Projekt und Ihre Organisation zu der geeigneten Vorgehensweise. Lassen Sie mich aus meiner Coaching-Praxis hierfür aber noch einen wichtigen Tipp mitgeben: Nicht gleich beim kleinsten Widerstand der Organisation Ihre Methode anpassen! Ver-suchen Sie es doch bitte so pur wie möglich und passen dann an, um noch besser zu werden (und nicht um noch angepasster zu werden).

1.2 Die Projektberichte

Jeder Projektbericht in diesem Buch ist in sich geschlossen und ohne den Rest des Buches zu verstehen und zu lesen. Die Lesereihenfolge ist daher frei wählbar. Im Folgenden beschreibe ich knapp, was Sie aus meiner Sicht in welchem Projektbe-richt erwartet. Ich empfehle Ihnen aber, auch die Kapitel zu lesen, die vielleicht nicht gleich für Sie passend scheinen, denn alle Berichte aus Projekten enthalten vielleicht doch an der einen oder anderen Stelle Hinweise für Sie, wie Schwierig-keiten gelöst werden können. Das mag nicht immer zu Ihren aktuellen Problemen passen, aber es schadet ja auch nicht, noch ein paar Ideen für die Zukunft im Hinterkopf zu haben und damit seinen Lösungsraum schon einmal zu erweitern.

1 Einleitung2

Holger Koschek berichtet in Kapitel 2 »Ein agiles Projekt ist kein Ponyhof« von einer von ihm begleiteten Einführung von Scrum in einem klassischen Organisa-tionsumfeld, das sich Veränderungen gegenüber zunächst nicht nur offen präsen-tiert. Es ist spannend zu lesen, mit welchen Konsequenzen welche Anpassungen vorgenommen wurden.

Bernd Schiffer hat eine seiner Erfahrungen als Scrum-Coach in Kapitel 3 »Scrum-Einführung bei einem Internet Service Provider – Leben und Werk eines ScrumMasters« niedergeschrieben. Er lässt uns teilhaben an interessanten Dis-kussionen und Entscheidungen, die Teams dort treffen mussten.

André Neubauer nimmt uns in Kapitel 4 »Scrum-Einführung bei Immobilien-Scout24« mit auf den Weg von ImmobilienScout24 hin zu einer Scrum-basierten Produktentwicklung. Dabei streift er auch ganz kurz das Thema Kanban für Ser-viceteams, deren Voraussetzungen für Scrum nicht geeignet scheinen.

Alex Bepple, Sven Günther und ich haben in Kapitel 5 »(Fast) agil in einem Großunternehmen« unsere Erfahrungen bei der Einführung eines agilen Entwick-lungsprozesses in einem größeren Unternehmen festgehalten. Den einzuführen-den Prozess haben wir immer mehr an Scrum orientiert, aber die Einschränkun-gen und Anpassungen waren erheblich und mehr als uns lieb und im Endeffekt gut war. Der Bericht hat nur ein sehr bedingtes Happy End, wir haben aber trotz-dem viel gelernt und wollen diese Erfahrungen gerne mit Ihnen teilen.

Sven Röpstorff hat in Kapitel 6 »Zurück auf die agile Spur – Vom Micro-management zu Scrum« seine Erfahrungen aus einer agilen Transition beschrie-ben. Dabei war schon vorher Lehrbuchwissen vorhanden, aber es fehlte die Pra-xiserfahrung. Neben den Scrum-Managementpraktiken ging es auch um agile Entwicklungspraktiken, wie sie vor allem eXtreme Programming bekannt gemacht hat.

Andreas Leidig beschreibt in Kapitel 7 »Agile Softwareentwicklung als fun-damentaler Bestandteil einer Unternehmensgründung«, wie ein Unternehmens-gründer als Product Owner eines Scrum-Teams seine Vision umsetzt. Dabei tau-chen unterwegs durchaus auch Probleme auf.

Stefan Roock berichtet in Kapitel 8 »Erfolgreich im Festpreis« von einem Projekt mit ganz besonderen Herausforderungen an den Liefertermin in einem sehr klassischen Umfeld und unter Festpreisbedingungen. Interessant ist zu lesen, welche Adaptionen an den Entwicklungsprozess das Team vorgenommen hat.

Susanne Reppin beschreibt in Kapitel 9 »Kanban – so starten Systemadminis-tratoren« die Einführung von Kanban bei Xing. Susanne und ihre Kolleginnen und Kollegen standen vor einer nicht untypischen Situation: Eigentlich entwickelt man nach Scrum, aber für bestimmte Serviceaufgaben scheint dies nicht zu pas-sen. Lesen Sie selbst, wie Software-Kanban hier hilft.

Markus Andrezak lässt uns in Kapitel 10 »mobile.de agil« teilhaben an der Agilisierung von mobile.de mit seinen Ausprägungen Scrum und Kanban, die beide bei mobile.de im Einsatz sind. Außerdem bietet er auch viele Einsichten,

31.3 Der Anhang

warum Agilität gewollt wurde und wie schwierig es durchaus sein kann, die agi-len Werte zu vermitteln und nach ihnen zu handeln.

Christiane Philipps ist ein Start-up-Junkie und hat viele Start-ups kennenge-lernt. Ihre Erfahrungen hat sie in Kapitel 11 »Agilität in Internet-Start-ups« zusammengefasst. Davon können nicht nur andere Start-ups profitieren, denn in einer sich schnell verändernden Umwelt befinden sich mittlerweile die meisten Organisationen. Neben dem Management der Entwicklung beschäftigt sich ihr Bericht einerseits auch mit Softwarequalität und technischen Skills und anderer-seits mit dem schnellen Lernen durch Prototypen, die dazu dienen können, eine unübersichtliche und unklare Situation ein wenig klarer darzustellen.

Jutta Eckstein beschreibt in Kapitel 12 »Transparenz« nicht nur ein agiles Projekt, sondern auch unter dem speziellen Gesichtspunkt des agilen Wertes und Vorteils Transparenz ihre Erfahrungen aus sehr vielen Projekten. Dabei geht sie speziell auch auf die unangenehmen Folgen von Transparenz ein, denn meistens werden nicht nur erfreuliche Wahrheiten sichtbar.

Dr. Arne Roock ist Prokurist bei der it-agile GmbH und hat in Kapitel 13 »Agil bei it-agile: Pull in Vertrieb und Verwaltung« aufgeschrieben, welche Erfah-rungen ein agiles Beratungshaus beim eigenen Einsatz von Kanban erlebt.

1.3 Der Anhang

Im Anhang finden Sie neben kurzen Biografien der Autoren auch noch ein kom-mentiertes Literaturverzeichnis, in dem zu den dort für Sie ausgewählten Büchern kurze Beschreibungen zu finden sind, was diese Bücher leisten können.

1 Einleitung4

5

2 Ein agiles Projekt ist kein Ponyhof

Holger Koschek

In einem großen mittelständischen Unternehmen bekommen IT-Abtei-lung und Fachbereich die Chance, auf der grünen Wiese ein neues Anwendungssystem zu errichten. Die externen Architekturberater emp-fehlen Scrum als agilen Ansatz für das Projektmanagement, und das Unternehmen lässt sich darauf ein. Mit zunehmender Scrum-Erfahrung stellt auch dieses Unternehmen fest, dass ein agiles Projekt kein Ponyhof ist, sondern harte Arbeit – die sich aber lohnt, wie das Projektergebnis und die Motivation der Mitarbeiter belegen.

2.1 Der Weckruf

Alle waren zum Kick-off des neuen Projekts gekommen: Auftraggeber, Business-Analysten, Vertreter des zuständigen Fachbereichs, das designierte Entwickler-team und deren Linienvorgesetzte. Alle waren gespannt auf die Ideen, mit denen man das ehrgeizige Ziel erreichen wollte, von dem viele glaubten, dass es unmög-lich erreicht werden konnte. Und dann hatte auch noch das Gerücht die Runde gemacht, man wolle dieses Projekt mit einem agilen Projektmanagement-Frame-work namens Scrum durchführen. Was aber war dieses Scrum? Und was sollte daran besser sein? Dies zu beantworten, war unsere Aufgabe.

Mein Kollege Jo und ich hatten unseren Standardfoliensatz zur Scrum-Ein-führung im Gepäck. Als Präsentationsform wählten wir die mehrfach bewährte agile Version des Klassikers »guter Cop, böser Cop«. Es ist immer eine Freude, die Reaktion der Zuhörer zu erleben, wenn Jo mitten in der Präsentation seine erste Zwischenfrage stellt. Ich präsentierte gerade das Product Backlog und erläu-terte, wie dort fachliche Anforderungen beschrieben und nach dem Geschäfts-wert und anderen Kriterien bewertet werden, als Jo verbal grätschte: »Und wo sind die einzelnen Aufgaben, die zur Implementierung dieser Anforderungen nötig sind? Dahinter stecken schließlich viele verschiedene technische Details. Wenn ich die nicht kenne, dann kann ich doch unmöglich den Aufwand schätzen,

2 Ein agiles Projekt ist kein Ponyhof6

den die Umsetzung einer fachlichen Anforderung verursacht!« »Eine gute Frage!«, entgegnete ich seelenruhig, während in der letzten Reihe einige Zuhörer aufgeschreckt ihre Aufmerksamkeit auf unseren aufkeimenden Diskurs lenkten. »Ich möchte diese Frage mit zwei Anmerkungen beantworten. Erstens: Wir schät-zen nicht etwa den Aufwand für die fachlichen Anforderungen, sondern nur die relative Größe. Mehr können wir zu diesem frühen Zeitpunkt auch gar nicht tun. Zweitens: Die einzelnen Aufgaben legt das Team erst zu Beginn des Sprints fest, in dem diese fachliche Anforderung umgesetzt werden soll.« »Aber ist das nicht viel zu spät? Wie soll man denn auf Grundlage solch spärlicher Informationen eine vernünftige Projektplanung machen?«, echauffierte sich Jo. Ich gab darauf-hin einen kurzen Überblick über Planung und Controlling agiler Projekte. Spätes-tens jetzt waren alle Zuhörer hellwach. Wieder einmal hatten wir den Eindruck, dass Jo mit seinen Fragen den Nerv der Skeptiker traf. Sie galt es zu überzeugen – nicht hier und heute, aber im Laufe des Projekts. Deshalb luden wir alle ein, agi-les Projektmanagement live in unserem Projekt zu erleben. Gelegenheiten gab es viele: Sprint-Review und (nach Rücksprache mit dem Team) Daily Scrum standen jedem Interessierten offen, und ein transparentes Projektcontrolling sollte scho-nungslos den echten Status des Projekts offenlegen – jederzeit, für jeden sichtbar. Das war ein Novum – nicht allein in diesem Unternehmen. Wir wussten aus ande-ren agilen Coachings, dass uns diese Transparenz und Ehrlichkeit neue Skeptiker bescherte. Wir hatten aber auch erfahren, dass meist deren Neugier siegte und sie das Projekt zunächst einmal beobachteten, bevor sie es in der Luft zerreißen woll-ten (wozu es eigentlich nie kam).

Unser agiler Weckruf hatte wieder einmal funktioniert. Allen war klar gewor-den, dass dieses Projekt anders sein würde. Wir wollten eine positive Neugier wecken und Ängste abbauen. Die größten Ängste hatte das Entwicklungsteam, das war uns klar. Für diese Gruppe warf unsere Einführungsveranstaltung erfah-rungsgemäß mehr Fragen auf, als sie beantwortete. Deshalb hatten wir uns für den nächsten Tag mit dem Team verabredet, um Scrum aus deren Perspektive zu betrachten und gemeinsam einen Fahrplan für den Projektstart zu entwerfen.

2.2 Das Team findet sich

Wir trafen uns in kleiner Runde. Ein bewusst informelles Ambiente sorgte für eine Atmosphäre, in der wir uns ganz offen allen Fragen zu Scrum widmen konn-ten. Um uns langsam an die schwierigen Themen wie Eigenverantwortung heran-zutasten, begannen wir mit der Beschreibung des idealen Projektraums – und

Ihre Einführung in Scrum soll einen nachhaltigen Eindruck hinterlassen? Dann spielen Sie doch mit den klassischen Vorurteilen gegen agile Frameworks und Vorgehensmo-delle. So nehmen Sie auf eine augenzwinkernde Art und Weise allen Skeptikern den Wind aus den Segeln.

72.2 Das Team findet sich

wurden prompt mit dem ersten Problem konfrontiert. Die Entwickler kamen aus verschiedenen Abteilungen, und jede Abteilung hatte ihre eigenen Räume. Das Entwicklungsteam war also räumlich verteilt. Immerhin saßen alle im selben Gebäude, aber das half uns nicht weiter. Was tun? Der Auftraggeber verstand unser Problem und versprach, sich auf die Suche nach einem geeigneten Projekt-raum zu machen. Das Entwicklerteam gab ihm bei dieser Gelegenheit noch eine weitere Aufgabe mit auf den Weg: Er sollte sicherstellen, dass die alten Arbeits-plätze für die Dauer des Projekts freigehalten wurden. Wir vermuteten dahinter die Angst, den liebgewonnenen Arbeitsplatz nebst »Mitbewohnern« zu verlieren und nach Projektende einen schlechteren Platz zugewiesen zu bekommen. Als wir ein Teammitglied vorsichtig darauf ansprachen, erfuhren wir einen weiteren Grund: Sein Vorgesetzter hatte ihn nur zu 70 Prozent für das Projekt freigestellt und erwartete, dass er die restlichen 30 Prozent seiner Arbeitszeit am alten Arbeitsplatz mit anderen Aufgaben verbringen sollte. Als wir daraufhin die ande-ren Entwickler befragten, stellte sich heraus, dass mit einer Ausnahme alle nur in Teilzeit für das neue Projekt vorgesehen waren. Angesichts der strategischen Tragweite und des knappen Zeitplans dieses Projekts war das eine ungewöhnli-che Entscheidung, die wir aber vorerst akzeptierten. Wir wollten schließlich Sicherheit schaffen, anstatt weitere Unruhe zu stiften. Deshalb fuhren wir mit der Beschreibung des Teamraums fort. Wir erläuterten das Taskboard, an dem für alle sichtbar die Aufgaben des laufenden Sprints verzeichnet waren und der Fort-schritt notiert wurde. Wir erklärten noch einmal das Daily Scrum, in dem sich das Team täglich synchronisieren sollte, und hoben die große Bedeutung der Kommu-nikation im Team hervor.

Die Mitglieder unseres Teams kannten sich fast alle und schienen gut miteinander auszukommen. Sie freuten sich auf die anstehenden Aufgaben und die spannen-den neuen Technologien, die wir in diesem Projekt erproben und verwenden wollten. Als wir ganz nebenbei über diese Technologien und über mögliche Soft-warearchitekturen diskutierten, machten wir eine erstaunliche Erfahrung: Die Teammitglieder erwarteten von uns, den Beratern, fertige Architekturskizzen und Empfehlungen für die zu verwendenden Technologien. Ein wenig überrascht blickten wir in die Runde. Diejenigen, die diesen Wunsch geäußert hatten, waren nicht etwa frischgebackene Uniabsolventen, sondern gestandene Softwareinge-

Das Team verdient zu Beginn der agilen Reise besondere Beachtung. Ein Certified-ScrumMaster-Kurs wirft für die Teammitglieder weitere Fragen auf, weil der Kurs auf ihren ScrumMaster zugeschnitten ist, die Belange des Teams aber nur indirekt betrach-tet. Versetzen Sie sich in die Lage eines agilen Teamnovizen und Sie werden feststel-len, dass die agilen Werte, das eigenverantwortliche Handeln, planerische Tätigkeiten und die für erfolgreiches Teamwork nötigen Soft Skills am Anfang mehr Last denn Freude sind. Von den ausgeprägten handwerklichen Fähigkeiten, die von agilen Ent-wicklern erwartet werden, soll hier gar nicht die Rede sein.

2 Ein agiles Projekt ist kein Ponyhof8

nieure mit mehrjähriger Praxiserfahrung. »Wie kann man sich aus solch spannen-den technischen Diskussionen freiwillig heraushalten?«, schoss es mir durch den Kopf. Ich musste diese Frage nicht einmal laut stellen, um eine Antwort zu bekommen. Eigentlich waren es zwei Antworten. »Es ist hier so üblich, dass die Softwareentwickler von einem Architekten angeleitet werden, der die technischen Entwurfsentscheidungen trifft«, sagte einer, und ein zweiter ergänzte: »Und außerdem seid ihr als Softwarearchitekten für unser Projekt angekündigt wor-den. Stimmt das etwa nicht?« Doch, es stimmte. Und die Idee, das Projekt mit Scrum durchzuführen, war genau genommen erst während der ersten Architek-turdiskussionen entstanden. Da stellten wir nämlich fest, dass wir zwei Möglich-keiten hatten: Entweder verloren wir uns in theoretischen Diskussionen, ergänzt durch endlose Software- und Technologieevaluationen. Oder wir legten einfach los, um in kurzen Iterationen erste Ergebnisse zu erzielen. Wir hatten den desig-nierten Projektleiter deshalb vor die Wahl zwischen einem eher klassischen und einem agilen Vorgehen gestellt – obwohl das gar nicht unser ursprünglicher Bera-tungsauftrag gewesen war.

2.3 Der eigentliche Auftrag

Beginnen wir doch einmal ganz am Anfang: Unsere Aufwartung hatten wir tat-sächlich als Softwarearchitekten gemacht. Ausgestattet mit dem nötigen Archi-tektur- und Technologiewissen und einer gehörigen Portion Erfahrung, sollten wir gemeinsam mit dem Kunden auf der sprichwörtlichen grünen Wiese eine neue Softwareplattform für die Kernprozesse des Unternehmens entstehen lassen. Ist das nicht der Traum eines jeden Beraters? Fast ohne Rücksicht auf bestehende Infrastruktur und Applikationen sollten wir mit modernen Technologien und fri-schen Ideen die Softwarearchitektur für die nächsten Jahre definieren und imple-mentieren.

Die Diskussionen mit den Softwarearchitekten des Kunden waren spannend und meistens auch zielführend. Trotzdem beschlich uns das Gefühl, dass wir nicht schnell genug waren. Deutliches Indiz für eine Tendenz zum Theoretisieren war das Verhältnis von Design- zu Codierungszeit: Zwei Wochen Recherche und Dokumentation stand keine einzige Zeile Code gegenüber! Wir waren mittendrin im Wasserfall, Phase 2: Design. Dabei hatten wir noch gar keine Ahnung davon, was die zu entwickelnde Plattform fachlich zu leisten imstande sein sollte. Die Fachkonzeption (Wasserfall, Phase 1: Anforderungen) oblag nämlich einer ande-ren Abteilung, von der wir bisher weder ein Gesicht noch ein Dokument zu sehen bekommen hatten.

Der Tag, an dem wir die Kollegen aus der Fachabteilung kennenlernten und uns anhand eines Fachkonzepts über die fachlichen Anforderungen austauschten, markierte einen positiven Wendepunkt. Endlich wussten wir, wofür wir eine tech-nische Plattform bauen sollten. Technologie als Selbstzweck war noch nie unser