Wie schätzt man in agilen Projekten E-Book

Boris Gloger

• Herausgeber: Hanser, Carl
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2014

Seitenzahl: 287

Beschreibung

AGILES SCHÄTZEN //
- Raus aus der Schätzfalle: In Produkten denken statt Projekte verwalten
- Warum agiles Schätzen Ihre Produkte besser werden lässt
- Erfahren Sie, wie Kunde und Lieferant mit Preisen für Leistungspakete besser fahren als mit Stundensätzen
- Lernen Sie, wie Sie trotz Lastenheft agil entwickeln können
- Wie Ihr Team in Zukunft Lösungen anbieten kann, statt Anforderungen abzuarbeiten

Im klassischen Projektmanagement gleicht das aufwandbasierte Schätzen mehr einem Orakel als einer auf objektiven Messkriterien beruhenden Aussage. Die große Überraschung kommt meistens zum Schluss – kein Wunder, denn es werden normalerweise nichts anderes als Mutmaßungen über die Zukunft angestellt. Agiles Schätzen verabschiedet sich von kostspieliger Wahrsagerei und ersetzt sie durch den ständigen Abgleich mit aktuellen Erkenntnissen über die Anforderungen an das Produkt. Gedacht wird dabei in Funktionalität, nicht in Aufwänden. Und genau deshalb gehen agil geschätzte Projekte pünktlicher und im Kostenrahmen durchs Ziel, ohne Kunde oder Lieferant zu übervorteilen.
Boris Gloger erklärt Ihnen die Instrumente für die erfolgreiche Projektplanung und Produktentwicklung. Mit Magic Estimation werden Planungsphasen von Wochen auf Tage reduziert. Design Thinking macht aus endlosen Anforderungsworkshops kreative Momente, und mit Story Maps werden aus mühsam zu wartenden Gantt-Charts klare und übersichtliche Bilder.
Diese neuen Verfahren steuern Projekte transparent und bringen so Sicherheit in Ihre Planung. Das Schätzen und Planen von Projekten kann wirklich einfach sein – und dieses Buch zeigt, wie es geht.

AUS DEM INHALT //
Die Rolle des Product Owners als Gestalter // Design Thinking // Impact Mapping // Story Mapping // Releaseplanung // Schätzmethoden // Mit der Cycle Time den Flow steuern

"Boris gibt mit diesem Buch einen ausgezeichneten Überblick über die Herausforderungen und Rahmenbedingungen bei der Vorbereitung eines Scrum-Projektes. Er greift dabei Ansätze auf, die neue Perspektiven bieten und erklärt sehr anschaulich, wie man Kunden überzeugen kann, neue Wege zu gehen. Auch wer bereits eine Menge Scrum-Erfahrung mitbringt, wird aus diesem Buch eine Menge lernen."

Sven Röpstorff, Agile Coach und Autor von "Scrum in der Praxis“

Leseprobe

Der Titel des Buchs – ein Widerspruch in sich. Also hineinschauen und seine eigenen Vorurteile gegenüber agilen Vorgehensweisen und dem Thema Aufwandsschätzung bestätigt sehen. Das wäre ein Leichtes.

Aber auch in diesem Buch bricht Boris Gloger mit den Konventionen. Der Projektabbruch – in der klassischen Projektwelt ein schwieriges Thema – wird in der agilen Projektwelt zur positiven Möglichkeit im Umgang mit sich ändernden Budgets oder Produktanforderungen. Das Buch bietet einen Schnelleinstieg in SCRUM und die Rolle des Product Owner, um sich dem Thema der Aufwandsschätzung und der Planung von agilen Projekten zu widmen. Sicherlich kein einfaches Thema, aber dank der übersichtlichen Darstellung und des Gloger-typischen Schreibstils sehr gut zu lesen, zu verstehen und damit eine sehr empfehlenswerte Lektüre.

Oliver Kuklok, CEO corporate quality consulting

Boris gibt mit diesem Buch einen ausgezeichneten Überblick über die Herausforderungen und Rahmenbedingungen bei der Vorbereitung eines Scrum-Projekts. Er greift dabei Ansätze auf, die neue Perspektiven bieten, und erklärt sehr anschaulich, wie man Kunden überzeugen kann, neue Wege zu gehen. Auch wer bereits eine Menge Scrum-Erfahrung mitbringt, wird aus diesem Buch eine Menge lernen.

Sven Röpstorff, Agile Coach und Autor von „Scrum in der Praxis“

Das Schätzen ist einer der unbeliebtesten Prozesse in der Software-Entwicklung, dominiert von aufwendiger Rückschau und Rechtfertigung. Ich kenne kaum ein Team, das sich leichtfüßig beim Schätzen bewegt – zunächst. Wobei das Schätzen nicht per se gut oder schlecht ist. Es kommt darauf an, wozu ich es einsetze. Hier ist die Spanne allerdings weit und läuft von krasser Verschwendung bis hin zu hohem Nutzen. Leicht zu übersehen ist auch, dass bei agilem Schätzen das Ziel auf dem Kopf steht: Die Schätzung ist nicht mehr das wesentliche Ergebnis, eher ein Nebenprodukt, das von Statistik ersetzt wird. Der Wert entsteht durch den Informationsaustausch und -gewinn im Team, eben wegen einer Kooperation mit vielen Perspektiven.

Boris beschreibt in diesem Buch das State-of-the-Art-Handwerkszeug eines jeden guten Product Owner. Sei es Story- oder Impact Mapping, Design Thinking oder der Aufbau eines Backlogs. Es findet sich jedoch viel mehr im Buch: Es ist ein Appell, sich den wertsteigernden Tätigkeiten der Organisation zuzuwenden. Hier gewinnt das Buch vor allem durch die Abgrenzung der klassischen Projektarbeit von der agilen Produktarbeit. Vieles, was jahrelang in der agilen Szene gereift ist und schwer zu formulieren war, drückt Boris leicht und verständlich aus. Das Buch lohnt sich besonders, wenn man einen Einblick in die Gedankenwelt eines agilen Pioniers gewinnen möchte, Inspiration für eine andere Art zu arbeiten sucht, sein Handwerkszeug als Product Owner aufbessern möchte oder schlichtweg verstehen möchte, warum agile Entwicklung funktioniert und was man ändern muss dafür.

Sven Winkler, Agiler Coach und Organisator der Nürnberger Scrum Community

Das neue Buch von Boris Gloger nimmt sich mit dem Schätzen eines der in der Praxis am heftigsten diskutierten Themen der Softwareentwicklung vor. Seit Software entwickelt wird, streiten sich Auftraggeber/Product Owner und Entwicklung darüber, was ein Feature kostet und vor allem wieso so viel und warum es so lange dauert, wie es dauert. Die agile Entwicklung mit ihren Storypoint-Schätzungen hat in meiner Wahrnehmung diese Diskussion noch verschärft. Das Buch macht komplexe Features nicht günstiger, aber es gibt Team und Product Owner neue Werkzeuge in die Hand, mit denen sie nachvollziehbarere, genauere und vor allem andere Schätzergebnisse erzielen und die Unsicherheiten dabei transparent machen. Die neuen Ansätze sind überzeugend hergeleitet und heuristisch belegt. Ich bin gespannt, wie sie sich bei meinen Teams in ihrer Praxis bewähren.

Christian Popp, Bertelsmann, Head of Software Development

Dieses wichtige Buch erlaubt es dem Leser, tiefere und vor allem breitere Einblicke und Erkenntnisse in die Kunst der agilen und schlanken Produktentwicklung, mit dem Thema agilen Schätzens als Teildisziplin, zu gewinnen.

Insbesondere die Verknüpfung mit Konzepten und Methoden der schlanken Produktentwicklung wie Design Thinking, Lean UX und Lean Startup erleben wir in unserem Unternehmen als enorm hilfreich und wertstiftend.

André Stark, Managing Director, AutoScout 24 GmbH

„Genau! Die Diskussion über die Richtigkeit der Schätzung ist sinnlos. Dank Boris’ Buch habe ich verstanden, warum!“

Jodok Batlogg, CEO, CRATE TECHNOLOGY

Boris Gloger

Wie schätzt man in agilen Projekten

– oder wieso Scrum-Projekte erfolgreicher sind

Der Autor:

Boris Gloger, Geschäftsführer Boris Gloger Consulting GmbH, Baden-BadenKontakt: [email protected]

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. Autor 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 Autor 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.

© 2014 Carl Hanser Verlag München, www.hanser-fachbuch.de

Lektorat: Brigitte Bauer-Schiewek

Copy editing: Dolores Omann, Wien

Herstellung: Irene Weilhart

Umschlagdesign: Marc Müller-Bremer, www.rebranding.de, München

Umschlagrealisation: Stephan Rönigk

Gesamtherstellung: Kösel, Krugzell

Ausstattung patentrechtlich geschützt. Kösel FD 351, Patent-Nr. 0748702

Printed in Germany

E-Pub-ISBN: 978-3-446-43972-6

Inhalt

Cover

Anzeige

Impressum

Vorwort

Der Autor

Schätzen – eine Hassliebe

1 Ein Weg für Realisten

2 Was ist agil?

2.1  Den Kunden begeistern – Emotionen

2.2  Was macht agile Produktentwicklung aus?

2.3  Das Problem der klassischen Projektorganisation

2.4  Scrum in aller Kürze

2.4.1  Ein Paradigmenwechsel

2.4.2  Der Scrum Flow

2.4.3  Design Thinking in aller Kürze

3 Der Product Owner in seiner Rolle

3.1  Der Product Owner – eine Wesensbeschreibung

3.1.1  Perfektionismus – zwischen gut und böse

3.1.2  Produktmanager oder Product Owner – eine Typologie

3.2  Mit Scrum zur Produktqualität

4 Das Budget bestimmen: Schneller und besser ist billiger?

4.1  Wie hilft der Business Value dabei, Geld zu verdienen?

4.2  Preisbestimmung

4.3  Weniger ist mehr: das Minimum Viable Product

4.4  Der positive Projektabbruch

4.4.1  Change for free

4.4.2  Scope-Erweiterung

4.4.3  Scope-Verkleinerung

5 Das Produkt – die ersten Ideen

5.1  Projektphasen in der agilen Produktentwicklung

5.2  Exploration

5.2.1  Discovery-Phase

5.2.2  Interpretation-Phase

5.2.3  Ideation-Phase

5.2.4  Experimentation-Phase

5.2.5  Evolution-Phase

5.3  Implementierung – Scrum als Prozessmodell

6 Tools und Techniken während der Implementierung

6.1  Impact-Mapping

6.2  Prototypen

6.3  Das Wie und das Was – User Storys

6.4  Das Product Backlog

6.4.1  Eisberg – die Backlog-Struktur

6.4.2  Story-Mapping

6.4.3  Impact-Mapping vs. Story-Mapping

7 Entscheidungsgrundlagen schaffen – schätzen

7.1  Schätzmethoden

7.1.1  Magic Estimation

7.1.2  Das Estimation Meeting

7.1.3  Planning Poker

7.1.4  Team Estimation Game

7.1.5  Mini-Schätzspiele

7.2  Aufwand, Komplexität oder Funktionalität?

7.2.1  Warum schätzen wir in Funktionalität?

7.2.2  Die Velocity ermitteln – das Schätzen überflüssig machen

8 Planung und Durchführung größerer Projekte

8.1  Scrum-Teams sind klein

8.2  Große Teams in der Produktentwicklung

8.2.1  Planung im skalierten Umfeld – die Product Roadmap

8.2.2  Vom Product Owner zum Product-Owner-Team: Synchronisation während des Sprints

8.2.3  Die Prognose ersetzt den Plan

8.2.4  Monitoring – Darstellung des Fortschritts

8.2.5  Abhängigkeiten – das Umfeld

8.2.6  Cost of Delay

9 Das Ende der Taskschätzung

Ergänzende Literatur und andere Quellen

Endnoten

Vorwort

Mehrals 15 Jahre eigene Projektpraxis, zehn Jahre Scrum, die Erfahrungen als Gründer eines Unternehmens, als Beobachter und Begleiter der komplexen Projekte meiner Kunden, haben mich eines gelehrt: Aufwandschätzungen, Zeitschätzungen und viele andere Planungsaktivitäten, auf die viele Manager, Scrum-Teams und Projektmanager Wert legen, sind die Zeit nicht wert, die sie kosten. Mir ist aber bewusst, dass es vielen schwer fällt, vom Schätzen in seiner traditionellen Form loszulassen und einen neuen Ansatz zu wagen. Doch mit diesem Buch will ich diesen Ansatz vorstellen. Ich will zeigen, wie man über ein neues Verständnis des Schätzens zu einer besseren Planung kommt. Dabei erkläre ich nicht nur die derzeit gängigen Schätzverfahren, sondern gehe auf Ansätze wie das Design Thinking und das Skalieren der Product-Owner-Rolle ein. Es war mir wichtig, nicht nur diesen einen, in Wahrheit sehr kleinen Ausschnitt des eigentlichen Schätzens zu zeigen. Der wesentliche Punkt in der agilen Produktentwicklung ist, von Anfang an mit einer gänzlich anderen Haltung an ein Projekt heranzugehen. Daran kranken nämlich meiner Meinung nach viele Unternehmen und deren Projekte: An der eigenen Einstellung zum Kunden, zum User und zur eigenen Kreativität.

Mein besonderer Dank geht dieses Mal an Dolores Omann. Dieses Buch war ihre Idee, sie hat mich davon überzeugt, dass es gebraucht wird. Sie hatte den Teilnehmern bei einem Scrum-Training zugehört und ihre Not erkannt: Das Schätzen war das Thema, bei dem sich die meisten im Kreis drehten und es im Geiste nicht so richtig in ihren beruflichen Kontext integrieren konnten. Dolores textet und schreibt seit vier Jahren für mich. Dieses Mal ist es zu einem Großteil auch ihr Buch, denn sie hat mich besonders unterstützt und immer wieder motiviert, es fertigzustellen. Zwischen zwei anderen Buchprojekten schrieb ich mir das Schätzen innerhalb kürzester Zeit „von der Seele“ und habe ihr die Rohfassung in die Hand gedrückt. Ohne sie wäre dieses Buch unlesbar.

Ich möchte Ihnen mit diesem Buch ein Handwerkszeug mitgeben, mit dem Sie Ihren agilen Projektalltag meistern können. Die Techniken und Ideen sind keine theoretischen Entwürfe: Sie sind in der Praxis entstanden und sie entwickeln sich in der und durch die Praxis ständig weiter. Probieren Sie die Instrumente in Ihrem Umfeld aus. Ich verspreche Ihnen, Sie werden ein anderes Verständnis von sinnvollen Schätzungen bekommen und sichtbare Erfolge verzeichnen. Ob Sie nun als ScrumMaster, Product Owner, „klassischer“ Projektmanager oder Mitglied eines Scrum-Teams arbeiten: Vielleicht müssen auch Sie sich – wie die Teilnehmer in meinen Trainings – zunächst von bisherigen Denkmustern und Annahmen verabschieden. In diesem Buch werden Sie daher nicht nur lernen, welche agilen Schätzverfahren es gibt und wie sie funktionieren. Es geht darüber hinaus um ein neues Selbstverständnis der Menschen, die für den Erfolg eines Produkts verantwortlich sind. Es geht um neue Herangehensweisen an die Produktentwicklung. Und es geht schließlich um die Erkenntnis, dass Produkte die wichtigste Verbindung zwischen einem Unternehmen und seinen Kunden sind – diese Verbindung braucht einen neuen Stellenwert.

Dieses Buch, dieses „Produkt“, ist auch Ausdruck meiner langjährigen Verbindung zum Hanser Verlag, vor allem zum Team rund um Brigitte Bauer-Schiewek. Sie hat mich dazu ermuntert, aus diesem Thema tatsächlich ein Buch und nicht nur ein Heft zu machen, wie ich es ursprünglich geplant hatte.

Und schließlich danke ich meiner Frau Kathrin für ihre Geduld mit mir. Sie meistert viele Aspekte unseres gemeinsamen Alltags für mich mit, damit ich die Zeit habe, meine Gedanken zu Papier zu bringen.

Laxenburg, im Februar 2014

Boris Gloger

■ Der Autor

2002 führte Boris Gloger 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. Die Erfahrungen aus der Praxis lässt er als Verbesserungen einfließen: So führte er die Rollen Kunde, Manager und Anwender ein und hob damit die Verbindung zwischen Produktentwicklung, Organisation und Markt hervor. Mit „Magic Estimation“ hat er das Schätzen in Scrum vereinfacht.

Bevor er 2008 die Boris Gloger Consulting GmbH gründete, war der Unternehmer als Business Analyst, Team-Leader, Projektmanager und Scrum Consultant für globale Unternehmen (z. B. EDS, Nokia, BenQ) tätig. Die Managementberatung Boris Gloger Consulting GmbH hat ihren Sitz in Baden-Baden und ist auf Training und Consulting für die agile Produkt- und Organisationsentwicklung mit Scrum spezialisiert.

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

■ Scrum. Produkte zuverlässig und schnell entwickeln. 4., überarbeitete Auflage, 2013.

■ Der agile Festpreis. Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge. 2012.

■ Erfolgreich mit Scrum: Einflussfaktor Personalmanagement. Finden und Binden von Mitarbeitern in agilen Unternehmen. 2011.

Kontakt: [email protected], www.borisgloger.com

Schätzen – eine Hassliebe

DasThema Schätzen begleitet mich seit meinem ersten Job bei Electronic Data Systems (EDS) in Rüsselsheim. Mit einem der Projekte wollten wir unter anderem zeigen, dass wir die Standards des Capability Maturity Models Level 2 erfüllen konnten – und ich wollte dafür den Projektplan erstellen. Wie man es eben so tut, hatten wir fein säuberlich alle Zahlen zusammengetragen und mein Projektplan war einfach toll. Als unser Entwicklungsteam die Designphase beendet hatte und das Projekt in die Implementierungsphase ging, war ich vor dem Status-Meeting mit meinen Entwicklern total nervös. War das Design wirklich fertig? Die zwei Entwickler, die sich bis jetzt um das Designdokument – damals hieß das „Technical Design“ – gekümmert hatten, sagten: „Boris, wir sind fertig, aber bitte sag es noch niemandem. Wir müssen noch einen Test durchführen. Bis übermorgen ist das aber erledigt.“ Zuerst verstand ich das nicht, ich war einfach nur total happy, weil mein Projekt auf Schiene war. Dann sagte Peter, der damalige Senior System Engineer: „Boris, du hast nicht verstanden: Wir sind fertig!“ Ich muss wohl ziemlich verdutzt aus der Wäsche geschaut haben. Peter sagte mir doch tatsächlich, das Projekt sei fertig implementiert und fertig getestet – und das drei Monate früher als es mein schicker Projektplan vorgesehen hatte. Ich war völlig perplex: Die geplanten 800 Entwicklungsstunden wurden nicht gebraucht. Die beiden Senior-Entwickler, die eigentlich „nur“ das Design schreiben sollten, hatten beides gemacht – und fertig entwickelt. Sie hatten sich also eigentlich nicht an den Prozess gehalten. Ich fragte sie, wie so etwas möglich sei. Die Antwort der beiden war vollkommen logisch: Eigentlich hätten sie das Design so aufbereiten müssen, dass das Offshore-Team genau verstanden hätte, was zu entwickeln war. In derselben Zeit konnten sie statt Pseudocode genauso gut den Code selbst schreiben.