Mike Cohn: Succeeding with Agile

Mike Cohn: Succeeding with Agile

Mike Cohn
Succeeding with Agile: Software Development Using Scrum

6. Druck von Februar 2012
2010 (Copyright), xxviii, 475 Seiten, Broschur
Addison-Wesley
ISBN: 978-0-321-57936-2



Die größten Fragen, denen Succeeding with Agile nachgeht, sind: wie führt man Scrum erfolgreich in einem Unternehmen ein und wie arbeitet man anschließend effizient in dessen Rahmen. Pragmatisch und sehr informativ lässt Cohn in diesem Buch den Leser an seiner langjährigen Erfahrung teilhaben.


Struktur

Mike Cohns Buch Succeeding with Agile weist eine relativ gute und nachvollziehbare fünfteilige Strukturierung auf:

  • im ersten Teil geht es um die Einführung von Scrum, um Probleme und Widerstände, die dabei auftreten können;
  • im zweiten Teil erörtert Cohn, was die neue Arbeitsweise für das Individuum bedeutet, um dann
  • im dritten Teil über die teambezogenen Prozesse zu sprechen;
  • im vierten Teil geht es um die Frage der Skalierung der neuen Arbeitsweise und um den Einfluss einiger Einschränkungen darauf, die z.B. durch gesetzliche Vorgaben entstehen;
  • im letzten Teil geht es um die Messung der eigenen Agilität.

Inhalt

Teil 1: Getting Started

Im Jahre 2010, als Cohns Buch in den USA erschien, war Scrum nicht mehr neu, somit waren die Probleme, welche einer Transition hin zu Scrum innewohnen auch nicht unbekannt. Anstatt nach Ausflüchten oder einfachen Lösungen zu suchen, räumt Cohn gleich im ersten Kapitel ein: Ja, Scrum einzuführen sei schwer und nein, eine Scrum-Transition gelinge durchaus nicht immer. Selbstverständlich kommt danach das große „Aber“, nämlich dass sich Scrum einzuführen aller Schwierigkeiten zum Trotz lohne. Anhand einiger empirischer Studien stellt Cohn fest, dass durch Scrum eine höhere Produktivität bei geringeren Kosten, aber auch eine höhere Qualität und mehr Zufriedenheit der Mitarbeiter und Stakeholder möglich sei (S. 11-16).

Die logische Folgefrage ist: Wie lässt sich denn Scrum erfolgreich(er) einführen. Jeff Hiatts ADKAR-Modell anpassend (ADKAR ist ein Akronym für Awareness, Desire, Knowledge, Ability, Reinforcement) führt Cohn das ADAPT-Modell ein (Awareness, Desire, Ability, Promotion, Transfer). Somit stehen am Anfang die Erkenntnis, dass sich etwas ändern muss (Awareness) gepaart mit dem Bedürfnis die Änderung auch durchzuführen und die Erkenntnis, dass Scrum eine Lösung für das Problem darstellt (Desire). Man muss selbstverständlich in der Lage sein Scrum zu verwenden: neben dem Wissen, wie Scrum funktioniert, ist auch der Einsatz technischer Praktiken vonnöten (Ability). Das allein reicht aber noch nicht und Cohn warnt davor, Scrum als etwas Entwicklungsspezifisches zu betrachten. Erfolge müssen nämlich bekanntgemacht werden (Promotion) und letztendlich muss ein Transfer der Arbeitsweise, auch wenn nicht unbedingt in vollem Umfang, auf die gesamte Organisation stattfinden.

Im dritten Kapitel wird es schon viel konkreter. So diskutiert Cohn Vor- und Nachteile eine gesamte Organisation auf Scrum umzustellen (im Gegensatz zu einem kleinen Teil davon) und Vor- und Nachteile eines offenen Umgangs mit der Transition (im Gegensatz zum sich bedeckt halten). Wie man das Wissen verteilt und wie die neuen technischen Praktiken eingeführt werden können, wird selbstverständlich auch diskutiert.

Kapitel vier geht auf sogenannte Enterprise Transition Communities ein, Gemeinschaften, deren Aufgabe es ist die Bedingungen für eine Scrum-Transition zu schaffen und zu verbessern und sogenannte Improvement Communities zu fördern. Letzteres bezeichnet Gemeinschaften von Personen, die sich zusammentun, um den Einsatz von Scrum im Unternehmen zu verbessern (S. 70).

Nach achtzig Seiten ist der Leser nun bereit das erste Scrum-Projekt anzugehen. Wann fängt man mit diesem an und wer soll Teil des Teams sein und nun ja, welches Projekt soll man überhaupt mittels Scrum durchführen, sind Fragen, die nun erörtert werden. Wie der Leser bis zu diesem Punkt jedoch schon gut weiß, die Änderungen bergen Risiken, es ist wichtig Erwartungsmanagement zu betreiben:

Scrum is not a silver bullet that will eliminate a development organization’s problems. You should work right from the start to make sure that expectations do not rise to unrealistic levels. Managing expectations will be perhaps one of the most important things you can do early on.

S. 92

Teil 2: Individuals

Dass sich durch Scrum in einem vormals nicht-agilen Unternehmen vieles ändert, ist selbstverständlich. Im zweiten Teil des Buches geht es darum was sich nun auf individueller Ebene konkret ändert. Welche neue Rollen gibt es und wer sollte sie besetzen? Welche Eigenschaften sind für einen Scrum Master (Cohn verwendet die Schreibweise „ScrumMaster“) oder einen Product Owner notwendig? Inwiefern kann eine Person mehrere Scrum-Rollen gleichzeitig innehaben und welche Rollen lassen sich eher zusammenlegen? Das sind die Fragen, die im siebten Kapitel besprochen werden.

Da die Änderungen nicht im luftleeren Raum stattfinden, stellt sich die Frage, was mit den ganzen Analysten, Architekten, Projektmanager und den anderen klassischen Rollen passiert. Diesem Thema widmet sich das achte Kapitel.

Lediglich neue Rollen einzuführen reicht jedoch nicht. Neue, agile Praktiken sind vonnöten und diese müssen beherrscht werden (das entspricht dem zweiten A der ADAPT-Methode, Ability).

Im neunten Kapitel geht Cohn auf folgende, durch das Extreme Programming popularisierte Techniken ein: Test-Driven Development, Refactoring, Collective Code Onwership, Continuous Integration und Pair Programming. Sehr offen stellt der Autor aber auch fest, dass das Leben durch das Fehlen einer initialen Design- und Planungsphase nicht leichter wird (siehe S. 167 f.). So stellt er fest, dass unter anderem das Planen schwieriger wird, aber auch die Parallelisierung von Arbeit. Scrum sei nichtsdestotrotz dem traditionellen Ansatz überlegen, da die Kosten einer anfänglichen Design- und Planungsphase, die der ständigen agilen Anpassung überwiegen würden (S. 168).

Nicht zuletzt, und damit beginnt eigentlich der zweite Teil (Kapitel 6), muss der Widerstand Einzelner aber auch der von ganzen Gruppen bei der Scrum-Transition berücksichtigt werden. Cohn identifiziert Gründe für den Widerstand und häufig anzutreffende Argumentationsmuster, denen sich die „Widerständler“ bedienen. Er beschreibt aber auch wie mit dem Widerstand umgegangen werden soll und wie die gängigen Argumente entkräftet werden können.

Teil 3: Teams

Nachdem sich Cohn den individuellen Aspekten gewidmet hat, nimmt er die teambezogenen Prozesse in Angriff. Der dritte und längste Teil des Buches beginnt mit Betrachtungen zur Teamgröße, -zusammensetzung und -struktur. Man merkt schnell: es reicht nicht, ein Team als selbstorganisierend zu bezeichnen, damit es das auch wird. Es erfordert Arbeit und Geschick, um aus einer Ansammlung von Menschen ein effizient arbeitendes (Scrum-)Team zu schaffen. Ebenfalls ist es wichtig als Team zu lernen und sich als solches weiterzuentwickeln. Scrum und Selbstorganisation sind kein Laissez-Faire, sie erfordern von den Führungskräften Erfahrung und Kompetenz (S. 233): „There is more to self-organization than buying pizza and getting out of the way. There are subtle and indirect ways through which leaders influence teams.“ Die Führungskräfte müssen diese subtile Beeinflussung meistern, wenn die „Selbstorganisation“ funktionieren soll.

Was jetzt noch fehlt sind die Prozesse: Anforderungserhebung, also das Produktbacklog (Kapitel 13), Sprints (Kapitel 14), Planung (Kapitel 15) und die Qualitätssicherung (Kapitel 16). Wenig verwunderlich, fordert Cohn bei Anforderungen den Fokus auf „Diskussionen“ statt auf „Dokumente“ zu legen, wobei er die Sinnhaftigkeit geschriebener Dokumente in manchen Situationen unterstreicht (S. 236 ff.). User Stories sind dabei das Mittel der Wahl um „Anforderungen“ festzuhalten (Cohn ist ebenfalls der Autor des 2004 erschienen und vielbeachteten Buches zum Thema User Stories Applied: For Agile Software Development). Interessanterweise fordert Cohn:

A user story on the product backlog does not need to be fully thought through, with every last detail worked out, before it is pulled into a sprint. In fact, we don’t even want items to be fully thought through.

S. 266 (fette Hevorhebung ist kursiv hervorgehoben im Original)

Es reiche, wenn eine User Story innerhalb eines Sprints detailliert werde, da die Kollaboration zwischen Entwickler und Product Owner auch während des Sprints weiter stattfände.

Sprints stellen dabei „Experimente“ dar, das Ziel der Planungssitzung ist die Identifikation des „most valuable experiment“ (S. 283). Während der Sprints findet ebenfalls eine Lernphase statt, man lernt das Produkt besser kennen, die Nutzer desselben und den eigenen Entwicklungsprozess. Am Ende des Sprints sollte immer ein fertiges Inkrement stehen. Cohn hebt die Wichtigkeit des Planens hervor und widerspricht denen, die agiles Vorgehen mit fehlender Planung gleichsetzen.

Teil 4: The Organization

Zwar wurden agile Methodologien im Allgemeinen eher für kleine Teams, die idealerweise in einem Raum zusammenarbeiten können, konzipiert, die Realität sieht aber oft anders aus: Projekte sind groß, es gibt viele Teams, die manchmal sogar an verschiedenen Standorten in verschiedenen Ländern sitzen. Die Fragen, die sich stellen, sind:

  • lässt sich Scrum skalieren?
  • und wie kann man verteilte Teams (erfolgreich) mit Scrum managen?

Auf die erste Frage ist Cohns Antwort ein klares „Ja“. Scrum skaliert durch das „Scrum of Scrums“, was zu einer Hierarchie von Teams führt (obere Ebenen bilden sich aus Repräsentanten der jeweils darunterliegenden Ebene), bis auf zusätzliche Planungssitzungen und Retrospektiven bleiben die Scrum-Prozesse dabei gleich. Kapitel 18 widmet sich verteilten Teams. Die Antwort Cohns darauf ist: es ist schwierig (auch weil verteiltes Arbeiten so schwierig sein kann), aber es kann funktionieren.

Das dritte und letzte Kapitel des vierten Teils geht auf die Frage ein: inwiefern lässt sich Scrum mit einem Standard wie ISO 9001 oder einem Modell wie das Capability Maturity Model Integration (CMMI) integrieren.

Part 5: Next Steps

Der letzte und sehr kurze fünfte Teil geht auf eine interessante Frage ein: wie lässt sich die „Agilität“ messen, Möglichkeiten hierzu werden in Kapitel 21 vorgestellt. Das Buch endet mit einem Appell zur ständigen Verbesserung und Weiterentwicklung:

I don’t care how agile you have become or how well you do Scrum. It doesn’t matter how good you are today; if you’re not better next month, you’re no longer agile. You must always, always, always try to improve.

S. 448

Diskussion

Über Scrum und die Scrum-Literatur kann viel Negatives geschrieben werden und manche haben sich nicht gescheut dies auch zu tun. Bertrand Meyers exzellentes Buch Agile! The Good, the Hype and the Ugly zeigt das Kritikwürdige daran überzeugend auf.

Mike Cohns Buch lässt sich jedoch nicht so einfach abweisen. Weder ist Succeeding with Agile ein Schnellschuss, noch vertritt es die Meinung, dass Scrum bloß richtig einzusetzen sei und schon würden Wunder passieren. Die praktische Erfahrung des Autors und seine pragmatische Herangehensweise sind überall im Buch erkennbar. Weder sei Succeeding with Agile ein Buch für Puristen noch eins für blutige Anfänger, sondern eins für Pragmatiker, die Hilfe mit dem „harder stuff“ (also die Einführung und alles, was dabei schieflaufen kann) bräuchten, lässt Cohn in der Einführung den Leser wissen (S. XXV).

Selbstverständlich geht das Buch davon aus, dass Scrum, auch wenn durch eine pragmatische Linse betrachtet, viel besser als alles wasserfallartige sei: „We know Scrum works. There is plenty of anecdotal evidence (and even some hard data) to prove this.“ schreibt Cohn auf Seite 87. Man könnte sich durchaus fragen, wieso “anecdotal evidence” ausreichend ist, um über die Effektivität von Scrum zu entscheiden; es handelt sich jedoch hierbei um eine kleine Schwäche, wovon es nicht viele im Text gibt. Aber wenn man schon entschieden hat, dass die Einführung von Scrum im eigenen Unternehmen das Ziel ist, dann kann das Buch eine kompetente Begleitung aller Höhen und Tiefen, die solch eine Transition mit sich bringt, darstellen.

Zwar ist das Buch zuweilen etwas verbos und langatmig, aber durch die Fülle an Information, durch den Pragmatismus und durch die tiefe Kenntnis der Gegebenheiten in Unternehmen, die eine Scrum-Einführung sowohl positiv als auch negativ beeinflussen können, stellt Succeeding with Agile eine empfehlenswerte Lektüre, für alle die eben dieses Ziel haben.


Zum Autor

Informationen über Mike Cohn finden Sie auf der separaten Buchautorenseite.


Folgende Rezensionen könnten Sie ebenfalls interessieren:

Petre Sora

Petre Soras Interessen sind vielfältig und befinden sich an der Schnittstelle zwischen Mensch und Informationstechnologie. Als studierter Psychologe und Software Engineer war er sechs Jahre als Java-Entwickler in mehreren Unternehmen tätig. Mit der Gründung der Rezensionsplattform nososo hat er sich entschieden eigene Wege zu gehen.

Schreibe einen Kommentar