Buchrezension: Wie schätzt man in agilen Projekten

Von | 18. April 2014
Wie schätzt man in agilen Projekten - oder wieso Scrum-Projekte erfolgreicher sind

Boris Gloger – 04/2014 160 Seiten. Fester Einband

Heute habe ich mal wieder die Ehre eine kleine Buchrezension zu veröffentlichen. Es geht um den Titel au dem Carl Hanser – VerlagWie schätzt man in Agilen Projekten – oder wieso Scrum-Projekte erfolgreicher sind. Wie schon öfters ist meine kleine Rezension etwas anders aufgebaut als üblich 🙂 Fakten -> Die Kapitel -> mein allgemeines Fazit!

Beginnen wir mal mit den einfachen Fakten:

  • Erschienen: April 2014
  • 160 Seiten
  • Preis 29,99 €
  • ISBN: 978-3-446-43910-8
  • Geschrieben von: Boris Gloger (Blog)

Link zum Buch: Wie schätzt man in agilen Projekten , das ganze gibt es auch als E-Book für 23,99 € in Form eines PDFs. Wer sich die gedruckte Variante kauft, kann das E-Book kostenlosen downloaden!

Das Buch stammt von Boris Gloger welcher bereit im Jahre 2002 sein erstes Scrum-Team leitete und welcher große Teilhabe an der Verbreitung von Scrum in Europa hat, behandelt das auch für mich nervige und unliebsame Thema „Schätzen“ – Ich glaube es gibt nur sehr wenige Menschen in der IT Branche die daran Spaß finden.

Kapitel 1 (Einführung) + Kapitel 2 (Was ist Agil)

Aber worum geht es nun genau, am Anfang des Buches erhält der Leser eine kurze Einführung zu den wichtigsten Elementen im Scrum, und einige sehr eindrucksvolle Statistiken über verpatzte Projekte und deren Schätzungen. Es werden alle notwendigen Rollen im Scrum-Team kurz mit ihren Aufgaben vorgestellt sowie das prinzipielle Vorgehen erklärt. Bereits in der Einleitung wird auf das Thema „Design Thinking“ eingegangen, welches nach Meinung von Boris Gloger einen nicht zu unterschätzenden Einfluss auf ein erfolgreiches Scrum – Projekt haben kann.

Kapitel 3: Der Product owner in seiner Rolle

Weiter geht es mit einer sehr ausführlichen Beschreibung der Rolle des „Product Owners“, insbesondere im Vergleich zum klassischen Produktmanager. Mir hat das Kapitel sehr gefallen. Was bereits hier klar wird, ist dass man ohne etwas Scrum – Know How seine Schwierigkeiten mit vielen Begriffen haben dürfte. Mir ist nun aber noch ein Stück klarer geworden wie die Rolle des „Product Owners“ in einem Scrum – Team zu definieren ist.

Kapitel 4: Das Budget

Welch eine Freude diese Kapitel, zeigt es doch gleich zu Anfang etwas von dem Wahnsinn, welchem viele von uns täglich ausgesetzt sind: Wir wissen nicht was wir wollen, ändern wird sich alles, aber wir möchten dann doch schon einen Festpreis 🙂 . Eine gewisse Begeisterung hat sich bei mir wirklich während des Lesens eingestellt, zeigt der Autor doch sehr spannende Ansätze diesem Dilemma in der Rolle „Product Owners“ zu entfliehen. Wenn das Buch so weiter geht, ist mein Notizblock bald voll!

Kapitel 5: Das Produkt

Nach dem Lesen dieses Kapitel kommt mir als erstes das Wort anstregend in den Sinn, aber sehr informativ. Es geht grob um die Entwicklung der Vision für das zukünftige Produkt, zu beginn wird auf die Problematik der bereits durch den Kunden gelieferten Anforderungen in Form eines Lastenhefts eingegangen und wie dieses ordentlich in User Storys zerlegt werden können. Ein nächster großer Brocken sind die Phasen, welche bei der Lösungsfindung durchlaufen werden:Exploration und Implementierung. Dieser Bereich ist sehr umfangreich beschrieben und fordert schon gute Konzentration beim Lesen. Sehr spannend waren für mich die Abschnitte zum finden der Produktidee (viele Geistesblitze) und die Vorstellung unterschiedlicher Methoden zum Abhalten der von uns allen geliebten Workshops!

Kapitel 6: Tools & Techniken

Im 6 Kapitel werden wie die Überschrift schon vermuten lässt Techniken vorgestellt, welche auch noch zum Einsatz kommen können wenn bereits Lastenheft oder sogar Projektplan erstellt sind, und man als „Product Owner“ in das Projekt geworfen wird. Hier geht es dann um die Personas, Users storys und das Impact Mappping. Daraus resultieren dann auch gute Beispiele zum Umsetzen des Backlogs.

Kapitel 7: Entscheidungsgrundlagen schaffen – schätzen

Es geht an das Eingemachte. Methoden zum Schätzen werden ausgiebig erläutert, einige wie das Planning Poker habe ich selber schon ausprobiert. Unter den Methoden gib es aber auch für den Scrum – Neuling vieles unbekanntes: Magic Estimation, Team Estimation Game und kurze Spiele für kleine „spontane“ Schätzungen. Das wichtigste ist aber das vorgestellte Paradigma nicht mehr in Aufwand oder Komplexität zu schätzen sondern nach Funktionen. Kein leichter Stoff aber sehr interessant.

Kapitel 8: Planung und Durchführung größerer Projekte

Ich muss gestehen, dieses Kapitel hat mich entweder überfordert oder man hätte es „einfacher“ gestalten können. Inhaltlich geht es darum mehrere Scrum – Teams ggf. externe Dienstleister und andere Abteilung zu koordinieren. Hierfür werden wieder Techniken und Vorgehensweisen vorgestellt. Meine Wenigkeit hat aber spätestes beim „Scrum of Scrum“ geistig abgeschaltet. Ich denke hier muss man schon etwas mehr Scrum – Erfahrung in petto haben um mitreden zu können (als ich..).

Kapitel 9: Das Ende der Taskschätzung

Hier fällt mir noch eins ein: Post It’s 🙂

Mein Fazit

Ich hoffe bereits durch meine Gedanken zu den einzelnen Kapitel ist mein Fazit deutlich geworden, mir hat die Lektüre sehr gut gefallen, auch wenn Sie doch an vielen Stellen relativ komplex war. Sehr gut gefallen hat mir, das nicht nur auf der Entwicklung von Software rumgeritten wurde, sondern das es um „Produktentwicklung“ im allgemeinen ging. Der Aufbau ist sehr gelungen, nur ein paar mehr Illustrationen hätten nach meiner Meinung nicht geschadet. Empfehlen würde ich das Buch allen die sich bereits etwas mit der Materie von Scrum beschäftigt haben, und ganz wichtig: Offen für neue Ideen im Projektmanagement sind. Manch Urgestein aus der Projektleitung dürften sonst nämlich die Haare zu Berge stehen.