Buchrezension – Scrum von Boris Gloger

Von Zeit zu Zeit stoße ich auf Bücher, bei denen es sich tatsächlich lohnt diese von Anfang bis Ende durchzulesen. So ein Buch ist Scrum: Produkte zuverlässig und schnell entwickeln von Boris Gloger .

Prädikat: Hohe Praxisrelevanz!

In über 300 Seiten bündelt der Autor sein Wissen zu einem hervorragenden Kompendium, das ich selbst unter anderem für eine Inhouse Schulung mit meiner Abteilung nutzen konnte. Die Praxisrelevanz wurde mir dabei so richtig bewusst, als auf mehreren Community Treffen (wie dem Open Space) genau die Fragen aufkamen, die Boris in seinem Buch angeht. Schon während dem Lesen passierte es mir deshalb immer wieder, dass sich neue Fragen bereits kurze Zeit später von selbst klärten. In einem Kapitel wird beispielsweise klar kommuniziert, dass eine Vision essentiell ist, am Anfang der Entwicklung stehen und dem Team deutlich vermittelt werden muss. Mit dem Hintergrund, dass wir an unserem hauseigenen ERP-System bereits seit vielen Jahren entwickeln, fragte ich mich, inwieweit dies auch auf bestehende Produkte zutrifft und wie dem Rechnung zu tragen sei. Bereits zwei Seiten später wurde mir die Frage beantwortet. Selbst von manchen fälschlicherweise als Nichtigkeit abgetane Feinheiten werden berücksichtigt: Der Begriff Team ist für sich nicht eindeutig und lässt in der Praxis in Gesprächen immer wieder Missverständnisse entstehen. Dabei ist nicht klar, ob mit Team alle am Produkt beteiligten Personen oder nur das Entwicklerteam gemeint ist. Schade ist an dieser Stelle nur, dass der Autor zwar bemüht ist, klar zu differenzieren, aber hin und wieder dieser Ungenauigkeit verfällt.

 

Schwerpunkt

In einer Rezension von Chip.de heißt es, dass der gefühlte Schwerpunkt auf Scrum in großen Organisationen liegt. Es ist richtig, dass der Autor stets bemüht ist Fragen, die in diesem Kontext aufkommen, zu beantworten. Persönlich sehe ich aber den Schwerpunkt auf der Philosophie, den Prinzipien und Werten hinter Scrum. Das zeigen zum einen die Verweise auf weiterführende Literatur. Leading Change, Start With Why, First, Let’s Fire all the Managers, Creativity under the Gun oder Die Idee des Management 2.0 sind nur ein paar Bücher, aus denen rezitiert wird. Zum anderen zeigen das die durchdachten Aussagen, die ich dermaßen deutlich bisher noch nirgends lesen konnte. Boris vertritt z.B. die Meinung, dass “Scrum seinen Ursprung nicht in der Lean Production hat. So richtig das ist – der Ursprung liegt im Wissensmanagement”. Weiter stellt er klar: “In Wahrheit handelt es sich bei Scrum also um eine Produktentwicklungsmethode und nicht um eine Projektmanagementmethode”. Im Subtext schwingt beim Lesen einfach mit, dass die Basics genauso durchdacht und in Frage gestellt wurden wie es für das Experten Know How der Fall ist. So verwundert es nicht, dass er auch gleich mit der typischen 3-Rollen-Gliederung in Scrum aufräumt und ein 6-Rollen-Konzept vorschlägt. Sicherlich etwas, das oft an Scrum kritisiert wird. Deshalb weiße ich an dieser Stelle explizit darauf hin, dass gerade die Anfangskapitel nicht übersprungen werden sollten, nur weil es sich um vermeintliche Banalitäten handeln könnte. Dort finden sich richtige Erkenntnisperlen.

 

Entwickler sind nicht außen vor

Als Developer freut es mich besonders, dass Boris auf Entwicklungspraktiken wie Continuous Integration, Test Driven Development und Configuration Management als essentiell und erfolgsentscheidend hinweist. Nicht nur hinweist, sondern dem Ganzen auch die nötige Anzahl Seiten widmet. Darüber hinaus wird auch von technischer Schuld und den damit einhergehenden Problemen gesprochen. Ich stelle immer wieder in Gesprächen mit Product Ownern oder Scrum Mastern fest, dass ihnen der Begriff Evolvierbarkeit und die dahinter lauernden Falle, besagte technische Schuld, nicht geläufig ist. An die geneigten Leser, denen der Begriff ebenfalls nichts sagt: Füllt diese Wissenslücke!

 

Wo Licht ist, ist auch Schatten

Weniger gefallen haben mir die Illustrationen und Bilder, welche zum einen in Deutsch, zum anderen in Englisch und wieder welche in beiden Sprachen beschriftet wurden. An einigen wenigen Stellen gelang es ihm nicht seine Gedanken klar genug zu formulieren, sodass ich ihn über Twitter oder über eine seiner Mitarbeiterinnen um Aufklärung bat (welche ich dann auch erhielt). Dabei handelt es sich nicht um subjektives Empfinden, da meine Kollegen die Aussage ebenfalls nicht verstanden. Darüber hinaus ist bei dem Buchkauf zwar eine kostenlose Ausgabe des eBooks im PDF Format enthalten, eine Kindle Ausgabe sucht man leider genauso vergebens wie eine epub- oder mobi-Version. Außerdem stieß ich auf mehrere Fehler in der vierten Auflage, darunter falsche Kapitelverweise und nicht mehr erreichbare Links. Diese werde ich dem Autor zukommen lassen. Vielleicht ringe ich ihm dafür ein kurzes Interview ab?!

 

Fazit

Lesen – von Anfang bis Ende!

Mit Tag(s) versehen:

5 thoughts on “Buchrezension – Scrum von Boris Gloger

  1. Norbert Eder 20. März 2014 um 9:28 Reply

    Herzlichen Dank für die gute und ausführliche Buchrezension. Schon bestellt.

    Gefällt mir

    • Uli Armbruster 20. März 2014 um 18:25 Reply

      Würde mich über deine Meinung, wenn du es gelesen hast, freuen! Habe heute gerade mit dem Autor gesprochen, der meinte, dass im Juni sein neues Buch zum Thema moderne Personalführung herauskommt. Werde mir das auch zu Gemüte führen.

      Gefällt mir

  2. Boris Gloger 20. März 2014 um 20:19 Reply

    Hi, vielen Dank für die tolle Rezension. Es freut mich sehr, dass mein Buch so gut gefallen hat.

    Gefällt mir

  3. […] PO parallel zur Produktschulung regelmäßig Scrum Schulungen (Inhouse), las Bücher (Empfehlung hier), ging zu Scrum Stammtischen oder machten Online Trainings. Alternativ kann auch ein externer […]

    Gefällt mir

  4. […] Ich bin der Meinung, dass Menschen ihre Arbeitsweise nur dann gewinnbringend ändern und sich produktiv am Prozess beteiligen, wenn sie von der Änderung selbst überzeugt sind. Demzufolge wird das Ergebnis bei einer typischen Command-and-Control Führung im besten Fall ausbaufähig sein. Eine aus meiner Sicht erfolgsträchtigere Herangehensweise könne diese sein: Bilde zwei Gruppen und lasse jedes Gruppenmitglied frei entscheiden, welcher der beiden Gruppen es beitritt. Die eine Gruppe setzt ein exemplarisches Projekt/Produkt gemäß der bisherigen Vorgehensweise um, die andere implementiert nach der neuen. Ein halber Tag ist dafür natürlich ungeeignet. Ein Monat ist der Geschäftsleitung eventuell zu kostspielig. Aber einen angemessenen Zeitraum benötigt es, um die gravierenden Prozessunterschiede zu Tage zu befördern. Eine unabhängige Instanz, z.B. der Product Owner, ein Externer oder eine Anwendergruppe, beurteilen das Ergebnis. Darüber hinaus sollten die Teams auch ihre Ergebnisse untereinander vergleichen. Einen wesentlichen Punkt würde ich noch aufnehmen: Bei dem Produkt sollten neue Anforderungen hinzu kommen und sich gegebenen Anforderungen ändern, um zu sehen wie anpassungsfähig beide Vorgehen sind. Unter der Prämisse, dass die neue Herangehensweise gewinnt und die Diskussion ernsthaft und konstruktiv geführt wurde, kann das Gros der Gruppe überzeugt werden. Die restlichen Skeptiker kippen eventuell durch Schlüsselfiguren, sogenannte Meinungsmacher, oder bei den ersten Erfolgen. Es ließe sich noch viel dazu sagen, aber ich möchte es an dieser Stelle dabei belassen und mit einem Zitat abschließen, welches meiner persönlichen Einstellung entspricht: “Die Führungskraft führt nicht über die Inhalte, sondern sie führt über die Emotionen […]” (Boris Gloger, S. 302, Produkte zuverlässig und schnell entwickeln). […]

    Gefällt mir

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: