Cover

Inhalt

Titelei

Impressum

Inhalt

Vorwort zur 1. Auflage

Vorwort zur 5. Auflage

Über den Autor

1 Prinzipien, Geschichte(n), Hintergründe

1.1 Was ist Scrum?

1.1.1 Eine kurze Einführung in die Funktionsweise

1.1.2 Rollen, Meetings, Artefakte

1.2 Ein Begriff ‒ viele Einsatzmöglichkeiten

1.3 Scrum ‒ eine Bewegung entsteht

1.4 Warum Scrum funktioniert

1.4.1 Ford und Sloan ‒ die Ursprünge der Massenfertigung

1.4.2 Lean Manufacturing

1.4.3 Lean Product Development

1.4.4 Second Generation Lean Product Development

1.5 Durch teamzentriertes Arbeiten zur modernen Wissensorganisation

1.5.1 Kontrollierbarkeit des Unkontrollierbaren

1.5.2 Kontinuierliche Verbesserung ‒ Fast Feedback

1.5.3 Höhere Produktivität

1.5.4 Freude an der Arbeit macht leistungsfähig

2 Die Rollen ‒ klare Verantwortlichkeiten

2.1 Das Entwicklungsteam ‒ die Spezialisten

2.1.1 Wie baut man ein Scrum-Team?

2.1.2 Die Phasen der Teambildung

2.1.3 Probleme des Teams bei der Implementierung

2.2 Der Product Owner

2.2.1 Das Product Backlog

2.2.2 Das Produkt annehmen, verbessern oder ablehnen

2.2.3 Den Releaseplan bestimmen und managen

2.2.4 Die Verbindung zwischen Product Owner und Entwicklungsteam

2.2.5 Den Return on Investment bestimmen und sichern

2.2.6 Wer sollte die Rolle des Product Owners übernehmen?

2.2.7 Der Product Owner im skalierten Umfeld

2.3 Der ScrumMaster ‒ ein Change Agent

2.3.1 Scrum implementieren

2.3.2 Das Abarbeiten von Impediments

2.3.3 Die Arbeit mit dem Entwicklungsteam

2.3.4 Die Arbeit mit dem Product Owner

2.3.5 Die Steigerung der Produktivität

2.3.6 Hat der ScrumMaster einen Fulltime-Job?

2.3.7 Wer wird ScrumMaster?

2.4 Der Customer ‒ der Finanzier

2.5 Der User

2.6 Das Management ‒ die Stabilisatoren der Organisation

2.7 Die Rollen ausüben und klar trennen

3 Strategisches Planen in Scrum

3.1 Was ist Planen?

3.2 Planungsebenen: Strategie und Taktik

3.3 Die Vision

3.3.1 Der Product Owner formuliert die Vision

3.3.2 Wie erschafft man eine Vision?

3.4 Führungsaufgabe Visionsgenerierung

3.5 Constraints festlegen

3.6 Die User-Rolle ist tot ‒ es lebe die Persona!

3.7 Das Product Backlog

3.7.1 Hilfsmittel für das Verwalten des Product Backlogs

3.7.2 Product Backlog für große Teams und Multiteams

3.7.3 Was ist ein Product Backlog Item?

3.7.4 Product Backlog Items als User Storys formulieren

3.8 Priorisierung des Backlogs

3.8.1 Grundlage der Priorisierung: Business Value

3.8.2 Methoden der Priorisierung

3.9 Schätzen in Scrum

3.9.1 Vorhersagbarkeit und Schätzungen

3.9.2 Schätzen mit Storypoints

3.9.3 Magic Estimation

3.9.4 Die Velocity bestimmen

3.9.5 Der Releaseplan

3.10 Die Planung geht weiter

3.11 Die Zusammenhänge zwischen strategischer und taktischer Planung

4 Der Sprint ‒ das Produkt entsteht

4.1 Die grundlegenden Prinzipien des Sprints

4.2 Das Estimation Meeting

4.2.1 Durchführung des Estimation Meetings

4.2.2 Das Estimation Meeting mithilfe von Magic Estimation

4.3 Das Sprint Planning ‒ taktisches Planen

4.3.1 Sprint Planning Meeting 1 ‒ Briefing und Analyse

4.3.2 Sprint Planning Meeting 2 ‒ Design

4.3.3 Sprint Planning mit großen oder mehreren Teams ‒ Skalierung

4.4 Das Daily Scrum ‒ tägliche Synchronisation (reloaded)

4.4.1 Das neue Daily Scrum ‒ Version mit Taskboard

4.4.2 Das neue Daily Scrum ‒ Version ohne Taskboard

4.4.3 Mögliche Probleme im Daily Scrum

4.4.4 Daily Scrum für große und verteilte Teams

4.5 Sprint Review ‒ das Produkt vorstellen

4.5.1 Die Bedeutung von „fertig“

4.5.2 Ablauf und Regeln des Sprint Reviews

4.5.3 Konsequenzen aus dem Sprint Review

4.5.4 Das Sprint Review im skalierten Umfeld

4.6 Sprint-Retrospektive ‒ kontinuierliches Verbessern

4.6.1 Warum funktionieren Retrospektiven?

4.6.2 Lernen: ent-täuschte Erwartungen

4.6.3 Die sechs Schritte der erfolgreichen Retrospektive

4.7 Der Sprint selbst ‒ zwischen den Meetings

4.7.1 Der Ablauf des Sprints ‒ Kommunikation, Kommunikation, Kommunikation

4.7.2 Gemeinsamer Fokus

4.7.3 Die Aufgabe des Teams im Sprint

4.7.4 Die Aufgabe des Product Owners im Sprint

4.7.5 Die Aufgabe des ScrumMasters im Sprint

4.7.6 Was kann während eines Sprints passieren?

4.7.7 Wann kann ein Sprint abgebrochen werden?

4.7.8 Konflikte ‒ es menschelt

4.7.9 Verlängerung des Sprints

4.7.10 Die Scrum Engine ‒ zermürbende Monotonie

5 Reporting ‒ wissen, wo wir stehen

5.1 Das Sprint Burndown-Chart

5.2 Das Taskboard

5.3 Das Story Burndown-Chart

5.4 Das Release Burndown-Chart

5.5 Das Parking-Lot-Chart

5.6 Das Velocity-Chart

5.7 Das Logbuch

5.8 Das Impediment Backlog

5.9 Die Retrospektive

5.10 Das Sprint Review

5.11 Berichten im skalierten Umfeld

5.12 Elektronische Hilfsmittel

6 Professionalität: Test, Integration, Release

6.1 Professionalität und Risiko

6.2 Auswirkung der schlechten Qualität

6.3 Entwicklungspraktiken der Balanced Agility

6.3.1 Kontinuierliche Integration ‒ das Produkt entsteht

6.3.2 Qualität ‒ testen, testen, testen

6.3.3 Release-Durchführung ‒ das Produkt zur Verfügung stellen

6.4 Kontinuierliches Liefern

7 Scrum skalieren

7.1 Die Prinzipien skaliert

7.2 Skalieren ohne Blueprints

7.2.1 Das skalierte Daily Scrum und das Scrum of Scrums

7.2.2 Wöchentliche Meetings

7.2.3 Skaliertes Estimation Meeting

7.3 Die Rollen skaliert

7.3.1 Das ScrumMaster-Team

7.3.2 Das Product-Owner-Team

7.3.3 Die Gilden ‒ Communities of Practice

7.3.4 Support-Teams

7.4 Skalieren über die Architektur

7.5 Verteilte Standorte

7.5.1 Das verteilte Team ist zu groß

7.5.2 Zu viele Meetings

7.5.3 Elektronische Tools

7.5.4 Das Linienmanagement

7.5.5 Visionen und Rahmenbedingungen

7.5.6 Wo sitzt der Product Owner?

7.5.7 Wo sitzt der ScrumMaster?

7.5.8 Freiberufler oder Mitarbeiter anderer Unternehmen im Team

8 Leadership, Emotion, Kreativität

8.1 Leadership

8.1.1 Arbeit an der eigenen Persönlichkeit

8.1.2 Circle of Safety

8.1.3 Entscheidungen einfordern

8.1.4 Fokus auf das Funktionierende

8.1.5 Positives bemerken

8.2 Emotionen

8.3 Kreativität

9 Scrum ‒ Management mit Werten

9.1 Fokus auf das, was wichtig ist

9.2 Commitment ‒ einander vertrauen

9.3 Offenheit ‒ aufeinander zugehen

9.4 Respekt ‒ Unterschiede würdigen

9.5 Mut ‒ neue Wege einschlagen

9.6 Das Produkt ist mehr als Strategie und Taktik

9.7 Scrum ‒ eine wertvolle Erfolgsgeschichte

10 Fallstudien

10.1 Holtzbrinck Legal/General Counsel: die agilen Anwälte

10.1.1 Mit Kanban beim Status quo starten

10.1.2 Daily Scrum und Retrospektive

10.1.3 Die Rechtsabteilung wird zur Serviceeinheit

10.1.4 Wissenstransfer

10.2 EWE: Energiekonzern mit agilem Antrieb

Literaturverzeichnis

Boris Gloger

Scrum

Produkte zuverlässig und schnell entwickeln

5., überarbeitete Auflage

Der Autor:

Boris Gloger, Geschäftsführer borisgloger consulting GmbH und borisgloger professionals gmbh, Wien – Baden-Baden, Kontakt: boris.gloger@borisgloger.com

Alle in diesem Buch enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die im vorliegenden Buch enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autoren und Verlag übernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Informationen – oder Teilen davon – entsteht.

Ebenso übernehmen Autoren und Verlag keine Gewähr dafür, dass beschriebene Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt deshalb auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen­ und Markenschutz­Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

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.

Dieses Werk ist urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren) – auch nicht für Zwecke der Unterrichtsgestaltung – reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden.

Lektorat: Brigitte Bauer-Schiewek
Copyediting: Dolores Omann, Wien
Herstellung: Irene Weilhart
Umschlagdesign: Marc Müller-Bremer, www.rebranding.de, München
Umschlagrealisation: Stephan Rönigk

Print-ISBN: 978-3-446-44723-3
Epub-ISBN: 978-3-446-45091-2

Verwendete Schriften: SourceSansPro und SourceCodePro (Lizenz)
CSS-Version: 1.0

Font License Zurück zum Impressum

Copyright 2010, 2012, 2014 Adobe Systems Incorporated (http://www.adobe.com/), with Reserved Font Name 'Source'. All Rights Reserved. Source is a trademark of Adobe Systems Incorporated in the United States and/or other countries. This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is copied below, and is also available with a FAQ at: http://scripts.sil.org/OFL ----------------------------------------------------------- SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007 ----------------------------------------------------------- PREAMBLE The goals of the Open Font License (OFL) are to stimulate worldwide development of collaborative font projects, to support the font creation efforts of academic and linguistic communities, and to provide a free and open framework in which fonts may be shared and improved in partnership with others. The OFL allows the licensed fonts to be used, studied, modified and redistributed freely as long as they are not sold by themselves. The fonts, including any derivative works, can be bundled, embedded, redistributed and/or sold with any software provided that any reserved names are not used by derivative works. The fonts and derivatives, however, cannot be released under any other type of license. The requirement for fonts to remain under this license does not apply to any document created using the fonts or their derivatives. DEFINITIONS "Font Software" refers to the set of files released by the Copyright Holder(s) under this license and clearly marked as such. This may include source files, build scripts and documentation. "Reserved Font Name" refers to any names specified as such after the copyright statement(s). "Original Version" refers to the collection of Font Software components as distributed by the Copyright Holder(s). "Modified Version" refers to any derivative made by adding to, deleting, or substituting -- in part or in whole -- any of the components of the Original Version, by changing formats or by porting the Font Software to a new environment. "Author" refers to any designer, engineer, programmer, technical writer or other person who contributed to the Font Software. PERMISSION & CONDITIONS Permission is hereby granted, free of charge, to any person obtaining a copy of the Font Software, to use, study, copy, merge, embed, modify, redistribute, and sell modified and unmodified copies of the Font Software, subject to the following conditions: 1) Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself. 2) Original or Modified Versions of the Font Software may be bundled, redistributed and/or sold with any software, provided that each copy contains the above copyright notice and this license. These can be included either as stand-alone text files, human-readable headers or in the appropriate machine-readable metadata fields within text or binary files as long as those fields can be easily viewed by the user. 3) No Modified Version of the Font Software may use the Reserved Font Name(s) unless explicit written permission is granted by the corresponding Copyright Holder. This restriction only applies to the primary font name as presented to the users. 4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font Software shall not be used to promote, endorse or advertise any Modified Version, except to acknowledge the contribution(s) of the Copyright Holder(s) and the Author(s) or with their explicit written permission. 5) The Font Software, modified or unmodified, in part or in whole, must be distributed entirely under this license, and must not be distributed under any other license. The requirement for fonts to remain under this license does not apply to any document created using the Font Software. TERMINATION This license becomes null and void if any of the above conditions are not met. DISCLAIMER THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE.

Vorwort zur 1. Auflage

Warum nutze ich Scrum, bin Scrum-Trainer, habe eine Consulting-Firma, die Kunden hilft, Scrum zu nutzen, und wieso versuche ich selbst, die Prinzipien, die hinter Scrum stecken, zu verwirklichen? Vielleicht ist es der gleiche Grund, der Sie bewegt, dieses Buch in die Hand zu nehmen: Ich bin unzufrieden.

Ich sehe jeden Tag, wie intelligente und gut ausgebildete Menschen zur Arbeit gehen und an ihrer Arbeit keine Freude mehr empfinden. Menschen wechseln den Job und hoffen, dass dieser Job die erhoffte Befriedigung bringt. Und am Ende sind sie wieder gelangweilt, schalten ab und wollen am liebsten zu Hause bleiben.

Ich habe gesehen, dass Software-Entwicklungsprojekte scheiterten, weil sich niemand verantwortlich gefühlt hatte. Es ist absurd: Projekte, an denen Dutzende Menschen hart und lange gearbeitet hatten, scheiterten, weil am Ende alle allen die Schuld gegeben hatten und nur noch jeder daran interessiert war, seinen eigenen Bereich zu verteidigen. Obwohl jeder Beteiligte früh sah, dass sich das Projekt auf dem Holzweg befand, wurde es fortgeführt, man ging mit offenen Augen auf den Abgrund zu.

Ich sehe Menschen, die ihr Leben im privaten Alltag meistern. Aber wenn sie morgens in ihre Firma gehen, werden sie dort zu ängstlichen Wesen. Menschen, die genau wissen, was sie können, trauen sich nicht, ihren Chefs zu sagen, dass die Anweisungen, die sie erhalten, sinnlos und unproduktiv sind. Sie bekommen in Besprechungen Schweißausbrüche, wenn sie etwas sagen sollen, oder sie sind froh, wenn sie den ganzen Tag nicht von ihrem Chef wahrgenommen werden.

Ich sehe Chefs von Software-Entwicklungsabteilungen resignieren, weil ihre Mitarbeiter nicht motiviert sind, nicht tun, was getan werden müsste, und abends lieber fluchtartig nach Hause gehen, als fünf Minuten länger in der Firma zu sitzen. Das Resultat sind Chefs, die in ihrer Verzweiflung beginnen, Kontrollmechanismen aufzubauen, die die begonnene Abwärtsspirale verstärken.

Das machte mich unzufrieden, und ich wollte das ändern. Ich dachte am Anfang, es läge an der falschen Art und Weise, Software-Entwicklung zu betreiben, an den falschen Methoden und Tools. Ich dachte, es läge an den falschen Managementmethoden oder daran, dass an den entscheidenden Stellen die falschen Leute sitzen. In der Rolle des Business-Analysten eines Entwicklungsteams vermutete ich zuerst, dass es am unterschiedlichen Sprachgebrauch von Software-Entwicklern und Fachabteilungen liegen musste und dass es doch einen Weg geben müsste, das babylonische Sprachgewirr aufzulösen. Kurz: Ich war auf der Suche nach der Methode, mit der man es richtig machen kann.

Dann, Jahre später, fand ich die Methode: Scrum. Auf den ersten Blick schien es so, als wäre Scrum die Antwort auf all die Fragen, die ich so hatte. Schnell stellte sich heraus, dass Scrum diese Antworten nicht liefern konnte. Scrum zeigte mir aber einen Weg, wie man die Antworten finden konnte, und machte klar, wohin man schauen musste, wenn man Probleme in der Software-Entwicklung lösen wollte. Scrum zeigte nicht, wie ich es richtig machen sollte. Scrum zeigte mir nur ständig, wo ich noch etwas tun musste. Ich musste meine Management-Skills verbessern, Mitarbeiter kündigen, neue Entwicklungsmethoden einführen, mich mit meinen Chefs anlegen ‒ einmal zog ich die Konsequenzen selbst. Also alles in allem Dinge, die unbequem sind, die man nicht unbedingt gerne tut und die viel harte Arbeit erfordern. Scrum machte es mir und vielen meiner Mitarbeiter also nicht leichter, sondern es schien, als würde es sogar schwerer werden. Aber uns fiel auf, dass sich diese Schwierigkeiten mit dem Erlernen und Trainieren einer neuen Sportart vergleichen ließ. Es machte Spaß und war befriedigend. Zwar ging es nicht ohne Aufwand und Mühe, ohne hartes Training, ständiges Wiederholen von bestimmten Übungen und ständiges Überprüfen und Evaluieren unseres Fortschrittes. Aber wir wurden belohnt. Unsere Produktivität stieg, wir hatten mehr Freude an der Arbeit, und unsere Chefs wurden mit jeder Woche zufriedener mit uns.

In diesem Buch möchte ich Ihnen zeigen, wie auch Sie diese Erfolge erzielen können. Scrum wird Ihnen einfach erscheinen und doch werden Sie ständig die Frage im Kopf haben: „Und wie funktioniert das bei mir?“ Sie werden sich fragen, ob Scrum für Sie anwendbar ist und ob es funktioniert.

Ich kann Ihnen diese Frage beantworten. Scrum und seine Praktiken sind erfolgreich. Hunderte von Firmen und Tausende von Projektteams nutzen Scrum und sind im Entwickeln von Software erfolgreicher geworden. Haben diese Teams noch Probleme? Ja, viele! Sie finden sogar ständig neue Probleme. Aber sie haben sich auf den Weg gemacht. Daher wissen sie, wie viel noch zu tun ist. Denn erst wenn man auf dem Weg ist, bemerkt man, wie viel Wegstrecke vor einem liegt. Wenn Sie für einen Marathon trainieren, bemerken Sie auch erst nach dem Beginn des Trainings, wie hart der Weg wirklich ist.

Dieses Buch enthält die Ideen von unzähligen Personen, denen ich zutiefst dankbar bin. An erster Stelle Ken Schwaber und Jeff Sutherland, die uns allen gezeigt haben, wie einfach es ist, das Chaos zu kontrollieren. Norman Kerth, der mir das Wesen der Projekt-Retrospektive gezeigt hat. Jean Tabaka, Stacia Broderick, Hubert Smith, Jens Østergard und vielen anderen aus der Scrum Community, die einerseits den Weg mit mir gemeinsam gegangen sind und mir andererseits durch viele Gespräche geholfen haben, Scrum besser zu verstehen.

Ich möchte meinem ersten Scrum-Team danken: Gillian, Sven, Graig, Jakob, Niki und Marc sind mit mir damals auf die Reise gegangen. Und ich danke meinem damaligen Chef Michael Schindelar, der uns einfach ausprobieren ließ, wie Scrum funktioniert.

Mein besonderer Dank gilt meinen Freunden und Mitarbeitern, die heute mit mir Scrum in der Form leben, wie ich es verstehe und wie es in diesem Buch beschrieben ist. Nicht zu vergessen die Teilnehmer der Trainings aus vier Jahren, die alle ihren Beitrag dazu geleistet haben, dass dieses Buch, so wie es vor Ihnen liegt, geschrieben werden konnte.

Scrum ist eine Reise mit dem Ziel, seine Fähigkeiten zu erkennen, Erfahrungen zu sammeln, dabei Teamgeist entstehen zu lassen und zu erfahren, Höhen und Tiefen zu erleben, um am Ende ein Produkt zu liefern, das uns selbst und unsere Kunden begeistert, auf das wir stolz sind, weil wir uns einbringen konnten, und das als Ergebnis ein Teil von uns ist.

Viel Spaß beim Lesen!

Vorwort zur 5. Auflage

Acht Jahre sind vergangen, seit ich die ersten Zeilen für dieses Buch geschrieben habe. Acht Jahre Scrum, agile Softwareentwicklung, agiles Projektmanagement, agile Organisationsentwicklung ‒ die Welt hat sich für viele Unternehmen verändert, denn die Ideen von Jeff Sutherland und Ken Schwaber sind durchgedrungen. Heute diskutieren wir mit unseren Kunden nicht mehr darüber, ob Scrum erfolgreich ist oder überhaupt funktionieren kann, sondern nur noch über das Wie im jeweiligen Kontext. Mit Hilfe von Scrum wird heute in den Vorstandsetagen über Unternehmensstrategien nachgedacht, es wird als Methode des Change Managements genutzt und selbst Hardware wird heute von Scrum-Teams entwickelt. Ikujiro Nonaka selbst antwortete 2012 bei einem Vortrag an der Wirtschaftsuniversität Wien auf die Frage, wie Unternehmen in Zukunft agieren sollten: „Macht Scrum!“ Und mittlerweile hat sich im Topmanagement herumgesprochen, dass Scrum dabei helfen kann, neue Antworten auf die immer gleichen Fragen zu finden: Wie wird das Unternehmen in Zeiten des globalen Wettbewerbs noch leistungsfähiger? Wie lassen sich die Mitarbeiter halten? Wie wird das Unternehmen im War for Talents zu einem attraktiven Arbeitgeber?

Acht Jahre nach der ersten Ausgabe dieses Buchs lag mir die mittlerweile fünfte Überarbeitung wie ein Stein im Magen. Sollte ich wieder nur ein paar Sätze austauschen, da und dort etwas deutlicher werden oder zumindest an einigen Stellen großzügig neue Erkenntnisse einfließen lassen? Ich habe mich dazu entschieden, ganze Passagen neu zu schreiben, überflüssige Metaphern rauszuwerfen und in manchen Kapiteln massiv einzugreifen ‒ etwa in Kapitel 7 zur Skalierung oder Kapitel 8 zur Führung. Vielleicht empfinden Sie meine Grafiken als Kritzeleien. Aber mir geht es um die Veranschaulichung, nie um das schöne Bild.

Alles in allem ist es mir wichtig, Ihnen ein modernes Scrum zu präsentieren: Mit neuen Ideen, weniger Pathos als bei der ersten Auflage, als oft meine eigene Begeisterung für das Thema mit mir durchgegangen ist, aber dafür mit noch mehr Beispielen, gelebten Ideen und Beiträgen meiner Kollegen Christoph Schmiedinger und Anton Jessner. Die beiden arbeiten jeden Tag mit Teams und räumen für sie Impediments weg, engagieren sich für sie beim Management und zeigen ihnen, wie das neue Arbeiten mit Scrum gelingt.

Dieses Buch lebt in der fünften Auflage von der Leistung meines Teams bei borisgloger consulting. Meine Kolleginnen und Kollegen zeigen Tag für Tag, dass unsere Ideen funktionieren, und ihre Kritik ist mir wichtig. Anders als bei der ersten Auflage bin ich heute in meinem eigenen Unternehmen von Experten umgeben, die beurteilen können, ob das, was zwischen den Buchdeckeln steht, gelebte Praxis ist oder beliebige Fantasien sind. Sie haben es für gut befunden und nutzen dieses Buch bei der Ausbildung unserer neuen Kollegen. Es steht also wirklich das drin, was uns in unserer Arbeit weiterbringt. Danke euch allen für euer Engagement!

Ein dickes Dankeschön geht an Dolores Omann, die wie bei jedem meiner Bücher schonungslos offenlegt, wenn ich nicht mehr einfach und klar schreibe, die jeden Satz fünfmal umdreht und dafür sorgt, dass meine Ideen lesbar werden.

Ein Dankeschön an meine persönliche Assistentin Janine Frensemeyer. Sie hat mir Zeit freigeschaufelt, damit ich mich wirklich ans Umschreiben machen konnte. Ich wäre nie weitergekommen, wenn sie nicht immer wieder gesagt hätte: „Nein, da machen wir keinen Termin, da wolltest du schreiben!“

Vielen Dank an Christoph Schmiedinger und Anton Jessner, die beide ein Kapitel für diese Auflage beigesteuert haben. Herzlichen Dank an EWE und Holtzbrinck für die Erlaubnis, die in diesem Buch enthaltenen Fallstudien veröffentlichen zu dürfen. Das macht ein solches Buch extrem wertvoll für die Praxis, denn es zeigt: Die neue Welt des Arbeitens existiert.

Schließlich gilt mein Dank meiner Frau Kathrin und meiner Familie. Vielen Dank, dass ihr mich so unterstützt.

Aber diese 5. Auflage könnte gar nicht erscheinen, wenn es nicht Sie, die Leser meiner Bücher und unseres Blogs blog.borisgloger.com gäbe. Danke, dass Sie die Ideen verbreiten und vor allem selbst umsetzen! Hätten Sie, hättet ihr nicht an die Ideen aus diesem Buch geglaubt und hättet ihr sie nicht ausprobiert, wäre Scrum in Deutschland, Österreich und der Schweiz nicht zu dem geworden, was es heute ist: Ein Weg für gelingende Wissensarbeit im 21. Jahrhundert. Macht weiter so und habt viel Spaß beim Lesen!

Laxenburg im April 2016

Boris Gloger

Die Scrum-Checkliste

Für die Scrum-Checkliste besuchen Sie bitte

www.borisgloger.com

Dort gibt es die Checkliste auf Deutsch beziehungsweise Englisch und alle Informationen über die Checklist-App.

Über den Autor

Boris Gloger führte 2002 sein erstes Scrum-Team beim österreichischen Mobilfunker ONE zum Erfolg. Als weltweit erster, von Ken Schwaber ausgebildeter Certified Scrum Trainer hat er wesentlich dazu beigetragen, dass sich Scrum in Europa, Südafrika und Brasilien als Standard der agilen Softwareentwicklung durchgesetzt hat. Bevor er 2008 die Managementberatung borisgloger consulting GmbH mit Sitz in Baden-Baden gründete, war der Unternehmer als Business Analyst, Teamleader, Projektmanager und Scrum Consultant für globale Unternehmen (z. B. EDS, Nokia, BenQ) tätig. borisgloger consulting bietet Training und Consulting zur agilen Produkt- und Organisationsentwicklung mit Scrum sowie zum agilen Management für Fach- und Führungskräfte an. Boris Gloger gilt inzwischen als einer der progressivsten Denker im Bereich Management und Organisation und ist ein gefragter Vortragender auf Managementkonferenzen.

Folgende Bücher von Boris Gloger sind im Hanser Verlag erschienen:

Kontakt:

1Prinzipien, Geschichte(n), Hintergründe