„Ein Scrum Team sollte genau so groß sein, dass man es mit zwei Pizzas satt bekommt“ – Buch Rezension Succeeding with Agile

Hallo zusammen,

die in den letzten beiden Einträgen erschienenen Hinweise auf Artikel im Java Magazin sind ja mittlerweile erschienen, auch die Buch-Rezension für das Buch „OSGi für Praktiker“ ist mittlerweile abgegeben und wird wohl demnächst erscheinen.

Heute würde ich gerne eine kleine Rezension für ein Buch schreiben, das ich vor einiger Zeit gelesen habe und das mich tatsächlich begeistert hat.


Succeeding with Agile – Autor Mike Cohn

Diejenigen die bereits Bücher von Mike Cohn gelesen haben, werden mir beipflichten, dass dieser sein Handwerk versteht und DInge oft direkt anspricht und so klarheit in viele Fragestellungen bringt.

Das vorliegende Buch ist mit Sicherheit das beste zum Thema Agiles Projektmanagement aller Bücher, die ich bisher zu diesem Thema gelesen habe (und das sind mittlerweile wirklich schon einige).

Gleich zu Beginn betont Mike, dass Scrum einzuführen und zu leben wirklich schwierig ist, weil

  • Scrum DInge verändert und Veränderungen erfordert
  • Scrum Fehler aufdeckt
  • Scrum nicht nur Bottom-Up (vom Entwickler getrieben) oder Top-Down (Managementgetrieben) funktioniert
  • Scrum-Adoptionen niemals abgeschlossen sind, sondern ein fortlaufender Prozess

Natürlich betont er in gleicher Weise, dass sich die Mühe dennoch lohnt, und zwar u.a. deswegen weil:

  • Man mit Scrum schneller Produkte für den Markt liefert.
  • Qualität und Motivation der Arbeit und aller Beteiligten steigt

Was mir sehr gut an dem Buch gefällt sind die auf diversein Seiten eingestreuten Hinweise á la „Things to do now“, hier empfiehlt der Autor Dinge, die man direkt anpacken kann, um die Scrum-Adoption zu verbessern. Dies sind beispielsweise Hinweise wie „Hänge noch heute ein Improvement Backlog“ in euerm Team-Büro auf.

Im Kapitel 2 geht Mike auf das ADAPT-Prinzip ein (Awareness, Desire, Ability, Promotion, Transport).

Was bedeuten aber jetzt die einzelnen Punkte?

Awareness?

Man muss sich, wenn man versucht agil zu arbeiten (und ganz besonders, wenn man versucht mit Scrum zu arbeiten) sehr früh bewusst sein, dass es überhaupt ein Problem in der Organisation oder im Vorgehensmodell gibt. Ist man sich dessen nicht bewusst, würde man wahrscheinlich erst gar nicht versuchen, Scrum zu adaptieren.

Buzzword hier ist „Selling the Problem, not the Solution“. Das heisst, um einen Lösungsansatz erfolgreich vermarkten zu können, muss zunächst mal „Werbung“ für das Problem gemacht werden, Bewusstsein geschaffen werden. Ist dies möglich, werden viele Unternehen gerne bereit sein, zumindest den Versuch zu wagen, Agile Vorgehensweisen auszuprobieren.

Desire?

Um erfolgreich agil arbeiten zu können, muss man den unbedingten Willen haben, erfolgreich zu sein und hierfür auch etwas zu tun. Der Autor nennt hier eine sehr schöne Analogie: Er meint, er sollte mehr Gemüse essen, ist sich auch der Notwendigkeit bewusst, aber ihm fehlt einfach der Wille, das auch wirklich durchzusetzen“. Gefällt mir.

Ability?

Um Agile Techniken etablieren zu können, muss man die entsprechenden Möglichkeiten hierzu schaffen.

Zum Einen muß man sich persönlich fähig fühlen, diese Herausforderung anzunehmen und zu meistern, zum Anderen müssen natürlich auch die Rahmenbedingungen stimmen, das heißt, das Umfeld muß eine Adaption von Agilen Techniken zulassen.

Transer?

Was bedeutet Transfer von Scrum? Transfer bedeutet, dass Scrum weit genug in alle Teilbereiche eines Unternehmens transportiert werden muss. Es ist enorm schwierig, Scrum nur in Teilbereichen eines Unternehmens zu etablieren (das kenne ich zur Genüge). Am besten funktioniert eine Adaption, wenn alle mitziehen.

Wieder schafft es der Autor, mit einer sehr schönen Analogie das Konzept zu erläutern:

Transfer von Scrum kann mit einer Rakete verglichen werden. Deren Antrieb muss die Rakete weit genug bis in den Orbit transportieren, damit eine Weltraummission erfolgreich sein kann. Funktioniert dies nicht, wird die Mission scheitern. (Cohn nennt dies Organizational Gravity, sehr schön)

Weiter geht es bei Cohn mit den sogenannten Scrum Adoption Patterns:

Es gibt verschiedene Patterns um Scrum zu adaptieren, Cohn nennt hier u.a. den Start-Small Pattern, das bedeutet, man startet mit 1-2 Teams und vergrößert die Anzahl agiler Arbeiter immer weiter, bis irgendwann hoffentlich das ganze Unternehmen agil ist.

Ein weiteres Pattern ist das ALL-IN-Pattern, dies ist das genaue Gegenteil von Start-Small – hierbei wird in einem Big-Bang eine Voll-Adoption von Scrum mit allen verfügbaren Entwicklerteams vollzogen.

Natürlich muss bei beiden Pattern genau abgewogen werden, welche Art und Weise am besten zum jeweiligen Unternehmen passt. Das Start-Small Pattern eignet sich natürlich am besten für Unternehmen, die sich selbst noch gar nicht 100% sicher sind, ob sie Scrum überhaupt adaptieren möchten. So kann man auf sehr einfache Art und Weise die Produktivität, Qualität der Arbeit und Motivation der gescrummten Teams mit denjenigen Vergleichen, die noch auf die althergebrachte Art und Weise arbeiten.

Die Big-Bang-Lösung hilft natülich bei einer schnelleren Adaption von Scrum, aber natürlich mit allen Problemen, die dadurch entstehen – Schwierigkeiten bei der Umsetzung, viel Veränderung in kurzer Zeit, mögliche Entwickler, die nicht mitziehen möchten. Trotzdem wäre das Big-Bang-Pattern mein Pattern der Wahl, da es meiner Ansicht nach essentiell wichtig ist, den Prozess mit möglichst allen Entwicklern, Abteilungen, Projektmanagern zu etablieren.

Cohn beschreibt noch weitere Patterns, und zwar wie man mit frischen Teams umgehen kann und so Scrum besser verbreitet:

Split and Seed –  Hierbei beschreibt Cohn die Möglichkeit, Erfahrene Scrum-Entwickler aus einem Scrum-Team herauszunehmen und als „Grundstein“ für neue Scrum-Teams mit unerfahrenen Entwicklern zu benutzen. Auf diese Art und Weise können neue Teams etabliert werden. Natürlich geht dies mit einem Performanceverlust einher, da neue Teams sich erst zusammenfinden müssen und auch unerfahrene Entwickler erst an das Thema herangeführt werden müssen.

Grow and Split – Dieses Pattern beschreibt die Vorgehensweise, Teams immer mehr wachsen zu lassen, bis sie schließlich zu groß für ein einziges Scrum-Team sind, und diese großen Teams anschließend zu splitten und zwei Teams daraus zu machen, usw. usw.

Ich persönlich bin mir da nicht so sicher, ob ich mit Herrn Cohn übereinstimme. Aus meiner praktischen Erfahrung kann ich sagen, dass Scrum Teams ungefähr 2-3 Sprints brauchen, bis sie wirklich performant zusammenarbeiten. Das Gefühl für ein Team muss sich wirklich erst entwickeln, die Teammitglieder müssen lernen, sich aufeinander einzustellen.

Cohn vertritt die Einstellung, dass es durchaus möglich und manchmal sogar erwünscht ist, funktionierende Teams zu splitten. Darüber würde sich vortrefflich diskutieren lassen.

Cohn betont ausserdem, dass es enorm wichtig ist, sich niemals auf seinen Lorbeeren auszuruhen, d.h. man sollte niemals darauf verzichten, neue Techniken (XP, Pairprogramming, TDD oder auch Techniken auf der Projektmanagementebene) auszuprobieren. Teams lernen sonst durch Scrum lediglich das inkrementelle Arbeiten. Inkrementelles Arbeiten ist aber nicht agiles Arbeiten.

Cohn führt hier das sehr interessante Beispiel von Shamrock Foods an, hier wurde tatsächlich auf der Ebene des Projektmanagements versucht, zumindest eine Art Scrum einzuführen, und zwar ganz ohne Softwareentwicklung (hier sieht man, dass Scrum zwar oft mit Softwareentwicklung in Verbindung gebracht wird, aber nicht zwingend darauf beschränkt werden muß).

Shamrock Foods hat einen 5-Jahres Plan aufgestellt, um ihr Management und ihr Produkt in Viertel-Jahres-Sprints zu verbessern. Die zuständigen Manager haben sich hier am Ende des Sprints off-site in einem Hotel getroffen und quasi eine Retrospektive des vergangenen Sprints durchgeführt. Der Titel eines Artikels hierzu lautet „Should you build Strategy like you build Software“, leider habe ich diesen nirgendwo gefunden, aber dieser ist bestimmt sehr lesenswert.

Das erste Projekt

Cohn stellt hier eine interessante Tabelle bereit, und zwar geht es um die Ängste verschiedener „Schichten“ in einem Projekt, wenn es um die Einführung von Scrum geht. Entwickler haben beispielsweise folgende Ängste in sortierter Reihenfolge:

  1. Mangelndes Bewusstsein
  2. Angst vor Unbekanntem
  3. Angst um den Job
  4. Angst vor Aufwand

Ängste des Managements sind folgende in sortierter Reihenfolge:

  1. Kontrollverlust (DAS ist meiner Ansicht nach einer der größten Probleme)
  2. Zeitverlust
  3. Bequemlichkeit
  4. Scrum bietet keine Antwort auf die Frage „Was ist für mich drin“

Weiterhin teilt Cohn alle Projektbeteiligten in verschiedene Gruppen ein:

  • Pragmatiker – Pragmatiker akzeptieren und praktizieren changes, hören sich Argumente an
  • Konservative – Konservative möchten gerne aktuelle Strukturen behalten, Bestpractices und Vorhersagbarkeit
  • Vorstösser – Rütteln an bestehenden Strukturen, Wollen Veränderung

Cohn bietet natürlich auch eine Definition verschiedener Rollen, die ich hier nicht wiederhole, da diese sich mit der bekannten Definition deckt. Was ich hier erwähne sind eine markante Sätze aus dem Buch zu den jeweiligen Rollen:

Scrum-Master: „Scrum-Master hat Verantwortung ohne Macht“, „Scrum-Master sagen nicht, schau was ich erreicht habe, sondern schau was ich geholfen habe zu erreichen“,“Scrum-Master comitten sich genauso wie jedes andere Teammitglied“.

Techleads: Techleads können laut Cohn durchaus Scrummaster sein, aber nur wenn sie die persönlichen Skills mitbringen.

ProductOwner: Jedes Team sollte laut Cohn einen eigenen haben, da der PO die Vision des Produktes vorantreibt, ein PO sollte folgende Attribute mitbringen:

  • A(vailable) – Er sollte für das Team erreichbar sein
  • B(usiness Savy) – Ein PO kennt sein Business
  • C(ommunicable) – Er muß kommunikationsfreudig sein
  • D(ecisive) – Er muß fähig sein, Entscheidungen zu treffen
  • E(mpowered) – Er muß die Kraft haben, für sein Produkt einzustehen.

 

Technical Challenges – hier sind einige Perlen aus dem Buch

„Jedes Stück Code das man produziert sollte qualitativ so hochwertig sein, dass man es sich ausdrucken und zu Hause an den Kühlschrank hängen möchte“ – Ein sehr schöner Satz, der viel über Code-Quality aussagt.;)

Ein weiterer schöner Spruch kommt von den BoyScouts of America : „Leave every Place a little bit cleaner than you found it“ – bezogen auf Code eine Perle;).

Collective-Code-Ownership ist wichtig – denn Code den jeder sieht tendiert dazu, sauberer zu sein – Analogie „Was hält man sauberer, das Bad das jeder sehen kann oder das Bad im Keller, das alle paar Monate mal benutzt wird?“

Fazit:

Das Buch ist eine Perle und hat sich einen festen Platz auf meinem Schreibtisch verdient. Selten habe ich so treffende Worte zum Thema Scrum gelesen. Meine Empfehlung lautet unbedingt kaufen und lesen!

 

Advertisements

Kommentar verfassen

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