Die Kraft von Scrum E-Book

Henning Wolf

• Herausgeber: dpunkt
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2014

Seitenzahl: 217

Beschreibung

Scrum ist ein leichtgewichtiger agiler Ansatz für das Projektmanagement, der schnelle und effektive Softwareentwicklung fördert. Dabei folgt Scrum einem Schritt-für-Schritt-Ansatz und fokussiert auf Wertschöpfung, Teamverantwortung und das enge Einbeziehen der Kunden. Scrum wird in der IT-Industrie bereits vielfach eingesetzt, doch auch jedes andere Projekt könnte von seinen Prinzipien profitieren. Dieses außergewöhnliche Managementbuch vermittelt in einem erzählenden Stil ein Verständnis der agilen Denkweise im Allgemeinen und des Scrum-Ansatzes im Besonderen. Aus der Perspektive Marc Berners, CTO einer Softwareproduktfirma, lernt der Leser die verschiedenen Aspekte kennen, die es zu berücksichtigen gilt, wenn man Scrum im Unternehmen einführt und in der Entwicklung erfolgreich einsetzen möchte. Das wichtigste Projekt Marc Berners steckt in großen Schwierigkeiten. Mit der Hilfe seines norddeutschen Scrum-Coaches Stefan wird die Vorgehensweise des Entwicklungsteams komplett geändert und das Projekt kann schließlich zum Erfolg geführt werden. Dabei werden viele der bisherigen Kernprobleme strukturell und nachhaltig beseitigt.

Leseprobe

Dipl.-Inform. Henning Wolf ist Geschäftsführer der it-agile GmbH mit Sitz in Hamburg und München. Er verfügt über langjährige Erfahrung aus agilen Softwareprojekten (eXtreme Programming, Scrum, Kanban) als Entwickler, ScrumMaster und Coach. Darüber hinaus hat er zahlreiche Artikel und Tagungsbeiträge über agile Softwareentwicklung verfasst und ist Autor der Bücher »Software entwickeln mit eXtreme Programming« und »Agile Softwareentwicklung«. Henning Wolf hilft Unternehmen und Organisationen im deutschsprachigen Raum, agile Methoden erfolgreich einzuführen. Er hält auch Impulsvorträge zu Scrum und agiler Softwareentwicklung für Unternehmen. Seinen Blog finden Sie unter www.henningwolf.de und per E-Mail erreichen Sie ihn unter [email protected]. Er freut sich auf Ihre Anfragen, Fragen und Ihre Kommentare.

Prof. Dr. ir. Rini van Solingen ist ein erfahrener Trainer, Coach, Autor und Berater. Sein Hauptgebiet ist das Management von Softwareentwicklung und Agilität, mit speziellem Interesse für die Anwendung von Scrum in weltweit verteilten Arbeitskontexten. Neben seiner Beratertätigkeit ist Rini ein Teilzeit-Professor an der Delft University of Technology, wo er die Abteilung »Education and Research on Globally Distributed Software Engineering« leitet. Am einfachsten erreicht man ihn über seine Webseite: www.rinivansolingen.nl/english oder per E-Mail: [email protected]. Er freut sich, von Ihnen zu hören.

Eelco Rustenburg leitet bei Xebia in den Niederlanden die Abteilung »Agile Consulting & Training«. Eelco ist ein passionierter Agilist und hat einen besonderen Fokus auf die Einführung agiler Methoden in großen Firmen. Er moderiert häufig Workshops mit Managementteams von Organisationen und sitzt in Steuerungskreisen agiler Einführungsprogramme. Aktuell arbeitet Eelco an agilen Strategien, agilem Anforderungsmanagement und wie man Scrum und agile Techniken auch außerhalb der IT-Welt anwenden kann (z.B. im Verkauf, Marketing, Hausbau). Sie erreichen Eelco per [email protected] für Agile/Scrum-Herausforderungen, Fragen oder Diskussionen.

Die Kraft von Scrum

Inspiration zur revolutionärsten Projektmanagementmethode

Henning WolfRini van SolingenEelco Rustenburg

Henning Wolf · [email protected]

Rini van Solingen · [email protected]

Eelco Rustenburg · [email protected]

Lektorat: Christa Preisendanz

Fachlektorat und Übersetzung: Henning Wolf

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-86490-164-5

PDF 978-3-86491-470-6

ePub 978-3-86491-471-3

Copyright © der deutschen Ausgabe 2014 dpunkt.verlag GmbH

Wieblinger Weg 17 · 69123 Heidelberg

Autorisierte Übersetzung der niederländischen Originalausgabe mit dem Titel

»De Kracht van Scrum«

von Rini van Solingen & Eelco Rustenburg. IBSN 978-90-430-2047-3

erschienen bei Pearson Education, Benelux, Copyright © 2010

Authorized translation from the Dutch language edition, entitled De Kracht van Scrum

by Rini van Solingen and Eelco Rustenburg, published by Pearson Benelux, Copyright © 2010.

Dieses Buch erschien bis Juli 2013 unter gleichem Titel als 1. Auflage im Addison-Wesley Verlag, München, ISBN 978-3-8273-3052-9.

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

Vorwort

Scrum ist eine wesentliche Innovation der Entwicklungsprozesse seit der Einführung des Wasserfallmodells in den 70er-Jahren. Der Wasserfall war der Versuch der IT-Industrie, einen standardisierten und professionellen Prozess zu haben. Mit Scrum werden die Prozesse wieder zielorientiert, leichter handhabbar und flexibler. In den letzten Jahren mussten viele Organisationen lernen, dass man Softwareprojekte nicht bis ins letzte Detail im Voraus planen kann. Scrum gibt hier die Kontrolle wieder zurück in die Hände der Geschäftsseite und fördert die enge Zusammenarbeit von Geschäftsseite und IT. In der heutigen IT-getriebenen Geschäftswelt ist dies eine Notwendigkeit. Nicht zuletzt durch das Internet sind viele traditionelle Firmen heute eigentlich Softwarefirmen. Man denke nur an Banken, Fluglinien, Autohersteller, Regierungen, Logistikunternehmen, Elektronikhersteller etc. Für alle diese Organisationen gilt, dass sie heute faktisch komplett davon abhängig sind, dass ihre Software richtig funktioniert und sich leicht an die Bedürfnisse des Geschäfts anpassen lässt.

Scrum stammt aus der Softwareindustrie und basiert auf Lean-Ansätzen und -Prinzipien. Aber auch wenn Scrum IT-orientiert ist, kann die IT-Industrie mit Scrum endlich sagen: »Liebe Geschäftspartner, wir haben Euch verstanden und wir werden mit Euch zusammenarbeiten, um Wert zu schaffen, und das so viel und so schnell wie möglich.« Scrum ermöglicht Geschäfte, Scrum entfaltet aber auch menschliche Möglichkeiten. Es hilft Firmen in kurzen Zyklen Mehrwert zu schaffen. In der IT-Industrie hilft Scrum, das Potenzial an Talenten in den Teams zu nutzen.

Wir, die Autoren, kamen und kommen häufig in die Verlegenheit, den Wert von Scrum zu erklären. Das ist auch kein Problem, es hat uns aber klar gemacht, dass der Wert von Scrum sich nicht automatisch jedem erschließt.

Deshalb haben wir uns zusammengetan und wollen mit dem vorliegenden Managementbuch einen Beitrag zum besseren Verständnis leisten. Das Buch bietet in einem erzählenden Stil ein Verständnis der agilen Denkweise im Allgemeinen und des Scrum-Ansatzes im Besonderen. Durch die Augen von Mark Berner, dem CTO einer Softwareproduktfirma, erlebt der Leser die verschiedenen Aspekte, die es zu berücksichtigen gilt, wenn man mit Scrum arbeitet. Das Ziel war, dass jeder diese Geschichte in zwei bis drei Stunden lesen kann.

Wir hoffen, dass dieses Buch einen Einblick für Praktiker gibt, wie man Scrum in der Praxis anwenden kann. Beim Schreiben dieser Geschichte haben wir uns gegen weitere Hintergrundinformationen entschieden. Das war eine ziemliche Herausforderung für uns, denn wir sind ja alle Scrum-Jünger und könnten mit vielen weiteren Details aufwarten. Wir haben uns aber immer und immer wieder dazu gezwungen, bei der Essenz zu bleiben. Der Wert dieses Buches liegt also in seiner Einfachheit, die weiteren Details zu Scrum bekommt man aus vielen anderen Büchern.

Ob uns dies gelungen ist, müssen andere bewerten. Die bisherigen Reaktionen von Managern und Vorständen, die die Geschichte gelesen haben, waren sehr positiv und ermunternd. Wir sind sehr stolz und zufrieden mit dem Ergebnis. Wir hoffen, dass vielen Lesern dieses Buch einen Einstieg in Scrum erlaubt und wir damit zu einer praktischen Anwendung von Scrum beitragen. Wir erwarten, dass dies in der IT in jedem Fall gelingt, aber auch darüber hinaus. Denn wir sind überzeugt, dass die Priorisierung nach Wert, das Ausliefern von Mehrwert, selbstorganisierte Teams und kurze Zyklen ein Gewinn sind für wirklich jede Umgebung.

Henning Wolf, Rini van Solingen und Eelco Rustenburg

Danksagung

Vielen Dank an alle, die zu diesem Buch beigetragen haben. Für die vorliegende deutsche Ausgabe insbesondere an meine Kollegen Markus Gärtner und Fabian Dittberner. Aber auch dem Rest des it-agile-Teams bin ich immer zu Dank verpflichtet, wir gehen unsere agile Reise nun schon seit fast 10 Jahren gemeinsam. Stellvertretend für alle anderen nenne ich hier mal meinen Geschäftsführerkollegen und Kindergartenfreund Stefan Roock.

Henning WolfHamburg

Inhaltsverzeichnis

1      In London

2      Scrum

Die Essenz

3      Ist Scrum etwas für uns?

Die Essenz

4      Der Scrum-Prozess

Die Essenz

5      Sollen wir es ausprobieren?

Die Essenz

6      Sprint-Vorbereitung

Die Essenz

7      Während des Sprints

Die Essenz

8      Den nächsten Sprint vorbereiten

Die Essenz

9      Sprint-Ende

Die Essenz

10     Wie die Geschichte endet

 Die Essenz

 Index

1 In London

Was für ein Tag!

Mit leichten Kopfschmerzen gehe ich zum Taxi, das mich zum Flughafen Heathrow bringen soll. Es regnet junge Hunde. Es sind nur ein paar Meter vom ausladenden Eingang unseres Kunden LogiStrux zum Taxi. Trotzdem schaffe ich es, durch den starken Regen komplett durchnässt zu werden.

Der Fahrer bleibt im Taxi. Ungeschickt gelingt es mir nicht auf Anhieb, die Tür schnell zu öffnen. Die ersten Regentropfen laufen mir den Nacken herunter. Als ich die Tür schließlich geöffnet bekomme und ins Taxi klettere, trete ich in meiner Hast mit meinem rechten Fuß direkt in eine große Regenpfütze. Sofort fühle ich das Wasser an meinen Zehen. Mist. Ich sehe einen Flug in einem durchnässten Anzug und nassen Socken vor mir.

Endlich ist das Wochenende da!

Es war ein langer Tag. Gestern wurde ich dringend zum Besuch unseres Kunden LogiStrux gebeten. Sie fragten schon freundlich, aber es war klar, dass es nur eine mögliche Antwort gab.

»Wären Sie so freundlich und nehmen an unserem Meeting von 13 h bis 17 h morgen an unserem Hauptsitz in London teil?«, fragte mich die persönliche Sekretärin des Vorstandsvorsitzenden am Telefon.

Ich hatte gerade genug Zeit, um nach Hause zu fahren, meinen Pass und ein bisschen Handgepäck zusammenzupacken. Meine Assistentin besorgte währenddessen schnell ein Flugticket für mich. Das Leben eines CTO ist nicht das einfachste.

Ich war vorher noch nie am Hauptsitz von LogiStrux. Ich hatte ihre lokalen Vertreter schon mehrmals darauf hingewiesen, dass es sicher geschickter wäre, wenn wir regelmäßig auch mit ihren Vorgesetzten direkt sprechen würden. Das wäre nicht nötig, sagten sie. Allerdings war ich jetzt plötzlich willkommen, wo wir zum zweiten Mal den Produktivstart um drei Monate verschieben mussten. Verständlicherweise erwartete ich keine angenehme Unterhaltung. Ich hatte aber auch nicht erwartet, dass es so hart kommen würde.

Jetzt sah ich im Taxi meine Notizen unseres Meetings durch. Ich müsste sie nicht wirklich lesen, weil ich sie bereits verinnerlicht habe. Auch wenn es mir gelungen ist, eine allerletzte Chance von LogiStrux zu erhalten, habe ich keine Ahnung, ob wir diese wirklich nutzen können. Wir haben drei weitere Monate, aber dann muss es wirklich fertig sein! Vielleicht müssen wir etwas an der Art ändern, wie wir vorgehen? Aber ich habe keine Ahnung, was. Zuvor war Christian, unser Projektleiter, absolut überzeugt davon, dass er alle verbliebenen Probleme innerhalb von zwei Monaten lösen könnte. Aber wir waren nicht erfolgreich. Damals hatte ich angekündigt, dass wir auf der sicheren Seite wären, wenn wir »nur drei weitere Monate« an LogiStrux als Verzug melden würden. Das musste ausreichen. Christian ist erfahren. Er hat in der Vergangenheit schon viel größere Projekte geleitet, es würde also alles gut werden.

Wurde es aber nicht, bei Weitem nicht. Ich halte es nicht aus.

Ich kann Christian nicht die Schuld geben, er ist wirklich gut. Er ist vorher noch nie in einem Projekt gescheitert. Selbst wenn er dafür Tag und Nacht arbeiten muss, er bekommt es immer hin. Aber bei diesem Projekt hat er es nicht hinbekommen.

Also wurde ich vor den Vorstand unseres Kunden zitiert und auseinandergenommen. Mit meiner ganzen Überredungskunst ist es mir jedenfalls gelungen, eine letzte Chance zu erhalten. Drei weitere Monate, aber keinen Tag länger.

LogiStrux ist wichtig. Nicht nur weil sie einer unserer größten Kunden sind und repräsentativ für den größten Teil unseres Marktes. Sie sind hauptsächlich wichtig für uns, weil die neuen Features für unser Produkt vor allem ihre Ideen waren, und wenn wir sie erfolgreich umsetzen, könnte es unserem Produkt einen ganz neuen Schwung geben. Der Markt ist gerade nicht so einfach, und mit den neuen Features könnten wir ganz klar neuen Nutzen anbieten. Es würde also nicht nur LogiStrux stärken, es wäre auch eine Stärkung unserer Firma, und das wäre in diesen Zeiten enorm hilfreich.

»Aber wie können wir sicher sein, dass wir wirklich in der Lage sein werden, in drei Monaten auszuliefern?«, frage ich mich selbst, als ich mein Notizbuch mit einem Seufzen schließe. Ich friere an meinem rechten Fuß. Ich ziehe meinen Schuh aus und wringe die Socke aus. Hätte ich doch trockene Kleidung bei mir, denke ich. Ich freue mich nicht gerade auf einen Flug im durchnässten Anzug.

Am Flughafen Heathrow beeile ich mich, um zum Check-in zu kommen. Auch wenn es noch eine Stunde ist, bis mein Flieger startet, weiß ich, dass die Zeit auf einem Flughafen manchmal schneller vergeht, als einem lieb ist. Das Check-in geht schnell vonstatten, aber die Dame gibt mir mein Ticket mit dem Hinweis, dass ich mich doch beeilen möge. Die lange Schlange vor der Security macht mich nervös. Als ich gerade angefangen habe, viermal die Minute auf meine Uhr zu schauen, bin ich schließlich durch. Es sind nur noch fünf Minuten, also laufe ich lieber. Plötzlich höre ich eine Ansage: »Mister Mark Berner, please make your way immediately to gate C7, or we will proceed to off-load your luggage!« »Wenn ich doch bloß Gepäck gehabt hätte«, dachte ich reuevoll, »dann hätte ich mich bereits im Taxi umziehen können.« Ich laufe durch den Flughafen, meine Schuhe in der einen, meinen Gürtel und mein halboffenes Handgepäck in der anderen Hand. Nur ein paar Leute nehmen davon überhaupt verwundert Notiz. Als ich am Gate ankomme, stelle ich zu meiner Bestürzung fest, dass ich zu spät bin. Die Flugzeugtüren sind bereits geschlossen. Eine Diskussion wäre völlig sinnlos. Es gibt keine Möglichkeit, dass sie die Türen des Flugzeugs wieder öffnen, auch nicht für einen durchweichten Deutschen, der verzweifelt nach Hause fliegen möchte. Sie buchen mich freundlich auf den nächsten verfügbaren Flieger morgen Nachmittag um 16 h um. Also eine weitere Nacht in London. Ich gehe besser und suche mir ein Hotel und versuche, meine Kleidung zu trocknen.

Ein paar Stunden später und einigermaßen wiederhergestellt, gehe ich in die Hotelbar. Ich habe mich unter der Dusche aufgewärmt und ein leichtes Essen im Hotel-Restaurant genossen. Ich habe mir sogar ein paar neue, trockene Sachen zum Anziehen gekauft. Ich fühle mich schon besser. Meine Kopfschmerzen sind verschwunden, sodass ich jetzt endlich ein bisschen mit dem Entspannen und Genießen des Wochenendes beginnen kann.

Die Bar ist fast leer. Scheinbar schaffen es die meisten Leute rechtzeitig nach Hause. Ehrlich gesagt, wäre ich jetzt auch lieber zu Hause. Ich setze mich an die Bar und bestelle ein Bier. Ein Mann sitzt an der Ecke der Bar. Er sieht aus wie ein Deutscher. Weil er ein buntes T-Shirt mit der Aufschrift »Morgen ist bestimmt Wind« trägt, nehme ich an, dass er aus dem Norden kommt.

»Cheers!«, sagt er zu mir und hebt dabei sein Lager-Bier.

»Unglaublich!«, sage ich und grinse zurück, »wann auch immer ich in eine Bar gehe, sitzt da immer ein Kerl aus Deutschland und versucht, sich zu betrinken!«

Er beantwortet meine Bemerkung mit einem Glucksen. Das Eis ist gebrochen. Ich biete meine Hand an und stelle mich vor: »Hallo, mein Name ist Mark Berner.«

Sein Name ist Stefan, und ich hatte recht: Er lebt in Hamburg. Sein Flug nach Hause geht morgen früh. Er war in New York und hatte einen Zwischenstopp in London. Er hat eine agile Konferenz in den USA besucht. Ich habe keine Ahnung, was das ist. Er erzählt mir, dass er eine Präsentation zu »Scrum« gemacht hat und wie man »Scrum« bei der Entwicklung von Spielesoftware einsetzt. Ich erkläre ihm, dass ich der CTO einer Softwarefirma aus München bin. Er erzählt mir, dass »Scrum« definitiv auch etwas für uns wäre.

Ich habe den Begriff »Scrum« bisher nur im Zusammenhang mit Rugby gehört. Da ist Scrum mehr oder weniger das, was man ein Gedränge nennt, also wenn alle zusammenstehen und die Köpfe zusammenstecken. Allerdings kann ich mir überhaupt nicht vorstellen, dass er eine Präsentation gemacht hat über die Verwendung von Rugby-Elementen bei der Entwicklung von Spielen.

Ich frage ihn also, was es damit auf sich hat. Im Rückblick betrachtet hat das meine Welt komplett geändert: »Also was hat Rugby mit der Entwicklung von Software zu tun?«

»Ich werde es dir erzählen, Mark«, antwortet Stefan, »aber nur, wenn du mir noch ein Bier bestellst!« Für mich ist er ja ein bisschen schnell mit dem Duzen, aber für ihn scheint das normal.

2 Scrum

Es stellt sich heraus, dass Scrum ein Ansatz zur Entwicklung von Software ist. Ein Ansatz, den ich ziemlich extrem finde. Stefan erzählt mir, dass Scrum in die Gruppe sogenannter »Agiler Methoden« fällt.

»Das Wichtigste an Scrum ist, dass man offen bleibt gegenüber neuen Einsichten oder Ideen (eigenen genauso wie denen des Kunden), seine Prioritäten und damit auch das Produkt anzupassen. Gleichzeitig arbeitet man in kurzen, vorhersagbaren Entwicklungszyklen, an deren Ende jeweils eine neue funktionierende Version des Produkts steht. Deswegen steigert sich die Qualität des Produkts, genauso wie das Vertrauen des Kunden.«

»Der Begriff ›agil‹ kann ziemlich verwirrend sein«, sagt Stefan, »weil er auch ›schnell‹ meinen kann. Dabei meint er eher ›flexibel‹, und das auf clevere Art und Weise. Dieses Missverständnis führt oft zu der falschen Erwartung, man würde mit Scrum sofort schneller entwickeln. Man kann mit Scrum auch schneller werden, aber das ist nicht das Hauptziel. Das Wichtigste an Scrum ist, dass man agiler wird, also flexibler.«

»Das Wichtigste an Scrum ist, dass man offen bleibt gegenüber neuen Einsichten oder Ideen (eigenen genauso wie denen des Kunden), seine Prioritäten und damit auch das Produkt anzupassen. Gleichzeitig arbeitet man in kurzen, vorhersagbaren Entwicklungszyklen, an deren Ende jeweils eine neue funktionierende Version des Produkts steht. Deswegen steigert sich die Qualität des Produkts, genauso wie das Vertrauen des Kunden«, erklärt Stefan.

»Ich kann es dir ganz einfach erklären, denn Scrum ist so einfach, dass es sogar auf einen Bierdeckel passt«, sagt Stefan. Er greift in seine Hosentasche und holt einen Bierdeckel heraus, auf dem ein kleines Schaubild Scrum erklärt.

Mit freundlicher Genehmigung der it-agile GmbH

»Ich erkläre es dir aber ganz in Ruhe und nach und nach. Echte Zusammenarbeit mit dem Kunden ist deshalb zwingend, weil der Kunde das Feedback gibt, das wir brauchen. Man hört oft, dass Anbieter kontinuierliche Beziehungen zu ihren Kunden anstreben. Allerdings schaffen es die meisten nicht, weil sie ihre Versprechen brechen und nicht vorhersagbar zuverlässig liefern. Scrum hilft dir, deine Versprechen einzuhalten. Es hilft, den Prozess auf transparente Art und Weise zu kontrollieren, für dich, aber auch für deinen Kunden.«

»Und«, fügt er hinzu »auf einer globalen Ebene machen wir sogar die Welt ein kleines bisschen besser. Du glaubst vielleicht, ich wäre verrückt, aber wenn alles an Softwareentwicklung effektiver wäre durch konsequentes Ausliefern dessen, was wirklich gebraucht wird, in höherer Qualität, dann könnten wir massenhaft Zeit, Geld und Strom sparen! Und dabei spreche ich noch nicht einmal von den Mengen an verschwendeten Papierdokumentationen mit Spezifikationen, die wir ständig überarbeiten und überprüfen. Aber so eine Leidenschaft für Nachhaltigkeit ist vielleicht zu viel für dich.«

Er grinst und schaut mich mit offensichtlichem Spaß in seinen Augen an. Ich zögere, ob ich ihn damit necken soll, dass er auch nett zum Planeten ist, wenn er den Frisör meidet, und wohl deswegen einen rasierten Kopf hat. Allerdings lasse ich es lieber. Ich glaube, dass es für ihn wirklich ernst ist mit der Nachhaltigkeit. Außerdem erklärt Stefan auch schon weiter: »Zusätzlich sind die Entwickler vollständig verantwortlich. Sie kontrollieren ihren eigenen Prozess. Ihre eigenen Meinungen sind deshalb wichtiger als der vereinbarte Entwicklungsprozess. Der Fokus des Teams liegt dabei auf dem Ausliefern eines funktionierenden Produkts, denn darum geht es doch, oder? Dokumentation kann auch wichtig sein, aber nicht so wichtig wie ein funktionierendes Produkt.«

Ich denke zurück an einen früheren Job, in dem ich die Aufgabe hatte, einen Standardentwicklungsprozess einzuführen. Das war ein ziemlicher Kraftakt, und jetzt sagt mir der nordische Windsurfer, dass Entwickler nur machen sollten, worauf sie Lust haben, und nichts zu dokumentieren brauchen?

»Moment mal,« sage ich, »das wird doch so nichts! Wenn Entwickler nur machen, was sie als wichtig empfinden, und nicht mehr dokumentieren, dann wird es Chaos, und das sehr schnell.«

»Wirklich sehr agil«, necke ich ihn.

Stefan hält dagegen: »Ich dachte, dass ich gerade erklärt hätte, dass Scrum nicht ›schnell‹ impliziert. Wenn du deinen Kunden genauso wenig zuhörst, dann kann ich mir schon vorstellen, wie erfolgreich deine Firma sein muss!« Er grinst mich an.

»Scrum funktioniert erstaunlich gut. Manchmal denke ich, dass es Zauberei ist, aber das ist es natürlich nicht. In den letzten Jahrzehnten haben wir in unserer Branche doch gelernt, dass Anforderungen niemals komplett sind und sich immer noch verändern. Dagegen sollten wir nicht ankämpfen; wir müssen es als Chance begreifen und mit der Veränderung arbeiten. Das ist genau das, was Scrum macht. Für das Geschäft ist es immer gut, wenn man auf Veränderungen reagiert. Genau dort kann man Wert schaffen.«

»Nein, es ist kein Chaos, Mark«, fährt er fort. »Scrum funktioniert erstaunlich gut. Manchmal denke ich, dass es Zauberei ist, aber das ist es natürlich nicht. In den letzten Jahrzehnten haben wir in unserer Branche doch gelernt, dass Anforderungen niemals komplett sind und sich immer noch verändern. Dagegen sollten wir nicht ankämpfen; wir müssen es als Chance begreifen und mit der Veränderung arbeiten. Das ist genau das, was Scrum macht. Für das Geschäft ist es immer gut, wenn man auf Veränderungen reagiert. Genau dort kann man Wert schaffen. In traditionellen Ansätzen wurde das nie berücksichtigt, weil es die Planung und die Budgets durcheinandergebracht hat. Den Umfang anzupassen oder die Anforderungen zu verändern, war nicht erlaubt. Das rigorose Abblocken von Anforderungsveränderungen war die einzige Möglichkeit, um Budget, Umfang und Zeit zu kontrollieren.«

Er fährt fort: »Deshalb ist es eine so gute Idee, wenn man einen Produktentwicklungsprozess einsetzt, dem Veränderungen willkommen sind! Oder sogar eine Art der Entwicklung etabliert, die Veränderungen sogar explizit befördert. Auf der Basis eines neuen Software-Releases werden zusätzliche neue Ideen doch viel klarer. Wenn man also wirklich erfolgreich sein will, muss man bereit sein für Verbesserungen durch neue Einsichten und Erkenntnisse.«

Stefan erklärt weiter: »Sieh es einmal so, Mark. In unserem Geschäft sprechen wir immer von Veränderungen von Anforderungen, aber in Wahrheit sind es doch Verbesserungen. Wenn Kunden oder Anwender eine Veränderung formulieren, geschieht dies doch nicht, weil sie das System schlechter machen wollen. Es geschieht, damit es besser wird. Ökonomisch betrachtet ist es deshalb hochgradig empfehlenswert, solche Anfragen sehr ernst zu nehmen und ihnen einen zentralen Ort im Prozess einzuräumen. Scrum macht genau das: Es folgt im Kern einem kontinuierlichen Verbesserungsprozess. Software ist ja letztlich nur ein Mittel, um Geschäftsprozesse effektiver oder effizienter zu machen.«

»Wenn Kunden oder Anwender eine Veränderung formulieren, geschieht dies doch nicht, weil sie das System schlechter machen wollen. Es geschieht, damit es besser wird. Ökonomisch betrachtet ist es deshalb hochgradig empfehlenswert, solche Anfragen sehr ernst zu nehmen und ihnen einen zentralen Ort im Prozess einzuräumen. Scrum macht genau das: Es folgt im Kern einem kontinuierlichen Verbesserungsprozess.«

Ich muss zustimmen, dass da etwas dran ist. Wenn man sowieso im Vorhinein weiß, dass es viele Veränderungen geben wird, dann sollte man einen Ansatz wählen, der mit diesen Veränderungen auch umgehen kann. Als wir vor einem halben Jahr das Projekt für LogiStrux anfingen, wusste keiner exakt, was wir für sie bauen würden. Ihr Konzept klang gut, und wir hatten Vertrauen. Allerdings konnten wir den tatsächlichen Nutzen der neuen Features nicht genau vorhersagen, alleine schon wegen der ansonsten benötigten Unmenge an funktionalen Details. Gerade weil es noch nichts Vergleichbares auf dem Markt gab, war es viel Arbeit, die genaue Funktionalität im Detail zu definieren. Die Gespräche mit den Anwendern ergaben, dass diese ganz verschiedene Vorteile und Einsatzszenarien der neuen Funktionalität sahen.

Wir machten einen Zeitplan für das Gesamtprojekt. Jetzt erscheint dies rückblickend ziemlich verrückt. Letztlich wussten wir doch, dass das Projekt niemals diesem Plan folgend verlaufen würde. Haben wir uns da nicht selber in die Tasche gelogen? Egal, es war ein Projekt, und Projektleiter benötigen Pläne, um ihren Job zu machen. Also erstellte Christian einen Plan. Und er hat ihn schnell erstellt. Auch der Kunde möchte schließlich einen Plan sehen. Wie soll er ohne Plan wissen, wann er was bekommt?

Es wurde im Projekt guter Brauch, dass LogiStrux die Anforderungen veränderte. Im ersten Jahr kamen sie mit drei sehr großen Veränderungen. Eine war so gravierend, dass wir fast von Neuem anfangen mussten. Nach dem ersten halben Jahr und diversen Treffen mit LogiStrux kristallisierte sich heraus, was wir tun mussten, um ihre Ideen umzusetzen. Unser Projektansatz konnte allerdings nicht mit so einer großen Menge an Veränderungen umgehen. Der vereinbarte Liefertermin geriet zunehmend unter starken Druck. Aber wir hatten ja ein Ziel zu erfüllen. Dieses Ziel war: die Installation des verbesserten Produkts bei LogiStrux am 1. April. Und jetzt sagt dieser Stefan, dass ein solches Ziel unsinnig sei? Aber wenn man so viele Veränderungen willkommen heißt, hat man doch keine Idee, was man genau am Ende ausliefert, oder?

»Angenommen du möchtest deinen Urlaub in Rom verbringen. Du überprüfst regelmäßig deine Wünsche und überlegst, was du während deines Urlaubs sehen möchtest, und du landest am Ende in Berlin. Dann bedeutet es doch nur, dass du wohl bewiesenermaßen schon am Anfang nicht nach Rom wolltest, oder? Es ist also alles gut.«

»Ja, warte mal einen Moment«, sage ich zu Stefan, »dein Ansatz lässt doch einfach zu viel offen! Wenn ich beispielsweise meinen Urlaub in Rom verbringen möchte und ich Scrum verwende, um dorthin zu kommen, dann kann es passieren, dass ich am Ende in Berlin stehe?«

»Genau!«, antwortet Stefan. »Überleg doch mal: Angenommen du möchtest deinen Urlaub in Rom verbringen. Du überprüfst regelmäßig deine Wünsche und überlegst, was du während deines Urlaubs sehen möchtest, und du landest am Ende in Berlin. Dann bedeutet es doch nur, dass du wohl bewiesenermaßen schon am Anfang nicht nach Rom wolltest, oder? Es ist also alles gut! Mit deinem herkömmlichen Ansatz wärest du in Rom gelandet, nur um dort stundenlang erfolglos nach dem Brandenburger Tor zu suchen.«

Mich trifft der Schlag. Ich muss zugeben, dass er schon wieder recht hat. Ich hätte mit meinem Ansatz zwar nach Rom kommen können, aber dort feststellen müssen, dass ich dort gar nicht hinwollte. Dasselbe gilt für unser Produkt. Unser Produkt ist ja nur dann von hoher Qualität, wenn es tut, was unser Kunde gerne möchte, und damit für sein Geschäft Wert schafft.

»Aber wie funktioniert das?«, frage ich, »Ich kann doch meinem Kunden nicht einfach sagen: ›Wir werden sehen, wann es fertig ist.‹ Die lachen mich aus. Unsere Kunden wollen wissen, wann sie ihr Produkt bekommen. So ist es eben.«

»Alle Aktivitäten, die schwierig sind und häufig Probleme verursachen, sollte man so oft wie möglich machen – nur dann wird man gut darin, und sie werden einfach! Das gilt auch für das Ausliefern eures Produkts: so viel und so oft wie möglich.«

»Genau«, antwortet Stefan ruhig, »und deshalb gibst du ihnen eine neue Version deines Produkts jeden Monat und lässt sie nicht jahrelang warten.«

»Jeden Monat?!«, frage ich überrascht, »Wir haben schon genug Probleme damit, jedes Jahr ein Release zu erstellen! Ich möchte nicht mal über die Probleme nachdenken, die wir hätten, wenn wir jeden Monat ein Release bauen müssten. Es wäre gar keine Kapazität mehr übrig, um noch Features zu entwickeln. Wir würden nur noch testen und Fehler korrigieren.«