Wie kam ich dazu?

Mich hatte es wieder einmal in die O'Reilly Abteilung verschlagen und als erstes stach mir da dieses Scrum Buch in die Augen. Mein erster Gedanke war: "Das sicherlich nicht!" Der Grund dafür ist, dass ich in meinem Studium Software-Engineering Paradigmen zu theoretisch gefunden und keinen Mehrwert für meine Arbeit darin gesehen habe. Mein Programmieransatz war eigentlich, die Aufgabenstellungen, die ich erhalten habe, immer so schnell und gut wie möglich umzusetzen. Damit bin ich auch lange gut gefahren. Alle anderen Aufgaben habe ich lange nur als Hinderung an der eigentlichen Arbeit angesehen.

Doch dann sah ich die anderen Bücher, die hauptsächlich über Programmiersprachen oder andere technische Finessen berichteten. Da ich für die Aufgaben, die ich derzeit erfüllen will und soll, alle technischen Kenntnisse habe, und auch gerade kein Projekt mit einer neuen Technologie ansteht, begann ich in diesem Scrum-Buch zu blättern.

Den letzten Anstoß dafür gab es dann, als ich darüber nachdachte, wie meine privaten Projekte, bei denen ich der "Auftraggeber" bin, derzeit dahin plätschern. Daher wollte ich mir aus diesem Buch Anregungen holen, wie ich diese Projekte wieder aktiver in Angriff nehmen könnte und dann auch über einen längeren Zeitraum dranbleiben würde.

Scrum

Worum geht's?

In diesem Buch werden die Werte, die Techniken, die Rollen und die Dokumente (Artefakte) des Projektmanagement-Frameworks Scrum vorgestellt.

Nach einer kurzen Einführung werden zunächst die Scrum-Werte näher beleuchtet:

Diese Grundwerte sollten eigentlich bei jedem Projekt selbstverständlich sein und bilden die Grundlage für das erfolgreiche Ausführen von Software-Entwicklungen. Allerdings habe ich mit Erschrecken festgestellt, was hier in meinem Arbeitsumfeld aber auch bei meinen privaten Projekten oft fehlt. Und interessanterweise scheint immer jener Wert am wichtigsten zu sein, der im Projekt nicht eingehalten wird. Aber in Wirklichkeit sind alle gleich wichtig und müssen gleich stark gelebt werden.

Danach wird die eigentliche Scrum Arbeitsweise genau erörtert. An dieser sind die folgenden Rollen beteiligt:

Folgende Artefakte sind in den Prozess involviert:

Der Scrum-Prozess versucht das Produkt zu realisieren, in dem Anforderungen des Product Backlogs in Sprints implementiert werden. Für ein Scrum Team hat ein Sprint immer die selbe Länge. (Ein Sprint sollte dabei 1-4 Wochen lang sein. Davon abhängig sind auch die Längen der Meetings, die jeweils eine fixe "Timebox" aufweisen sollten.)

Bei einem Sprint werden folgende Dinge durchgeführt:

  1. Sprint Planning Teil 1 - Der Product Owner präsentiert eine sortierte Liste an Anforderungen, die als nächstes umgesetzt werden sollen. Das Entwickler-Team erörtert mit dem Product Owner inhaltliche Fragen und schätzt, wie viele Anforderungen im nächsten Sprint umgesetzt werden. Es wird ein gemeinsames Sprint Ziel gesetzt.
  2. Sprint Planning Teil 2 - Das Entwicklerteam teilt die Anforderungen in Tasks auf, die maximal einen Tag dauern und plant so die technische Umsetzung des Sprints. Danach beginnt der Sprint.
  3. Daily Scrum - An jedem Tag des Sprints treffen sich die Mitglieder des Entwicklungsteam und diskutieren, welche Dinge seit dem letzten Daily Scrum erreicht wurden, was bis zum nächsten zu erreichen ist und was die Umsetzung behindert.
  4. Sprint Review - Am Ende des Sprints wird dem Product Owner präsentiert, was umgesetzt wurde und auch wirklich fertig geworden ist, laut der Definition of done. Dies ist die Möglichkeit des Product Owners Feedback an das Entwickler Team zu geben.
  5. Retrospektive - Das Entwickler-Team diskutiert für sich noch einmal, was im Sprint passiert ist. Was wurde gut umgesetzt? Wo gab es Probleme? So werden Verbesserungspotentiale in der Zusammenarbeit entdeckt und Fehler beseitigt. (Inspect and Adapt Prinzip)

Des weiteren wird im Buch noch die Produktvision angesprochen, wobei der Product Owner eine Motivation für das Produkt und eine grobe Produktbeschreibung abgibt. Damit sollten alle Beteiligten für das Produkt begeistert werden. Die Vision vom Produkt sollte aber auch omnipräsent sein (Flipchart, Aufkleber, Mauspad, ...), damit man das eigentliche Ziel nie aus den Augen verliert.

Außerdem wird das Estimation Meeting beschrieben, in dem der Product Owner das Entwickler-Team um Aufwandsschätzungen für zukünftige Anforderungen bittet. Diese Anforderungen sind zwar schon im Product Backlog, sind aber noch nicht genau genug für eine Umsetzung beschrieben.

Im abschließenden Kapitel werden Tipps für das Arbeiten mit Scrum in der Praxis beschrieben. Die wichtigste Botschaft dabei war: "Nütze die Retrospektive!" Sie ist das Mittel, um den Arbeitsprozess zu verbessern, Hindernisse aus dem Weg zu räumen und die Umsetzung des Produkts zu optimieren.

Warum gefällt es mir so gut?

Das Buch ist gut geschrieben und nicht zu theoretisch. Man kann damit auch sehr gut arbeiten, wenn man nur bestimmte Details vertiefen will. Der Anhang bietet einen Index mit den wichtigsten Begriffen, die daraufhin kurz beschrieben werden. Um diese Themen vertiefen zu können, gibt es Seitenangaben, wo man Details nachlesen kann.

Meine Erfahrungen in der IT und die Anregungen des Buchs decken sich größtenteils. Es gibt für mich viele Anregungen, die ich in meine Arbeitsweise einfließen lassen kann. Ich werde wahrscheinlich niemals reines Scrum in meinem Arbeitsumfeld haben, weil es entweder in der Firma nicht einführbar ist, bzw. weil ich in meinen privaten Projekten alle Scrum-Rollen in Personalunion machen muss. Aber es gibt sicher einige Dinge, die ich für meinen Arbeitsprozess nützen werde.

Außerdem haben mich einige Diskussionen darin wirklich begeistert. Hier ein paar Beispiele:

Für wen ist das was?

Ich finde das Buch ist eine Bereicherung für jeden, der an Software-Projekten arbeitet und nach Verbesserungen in seiner Arbeitsweise sucht.

Scrum ist zwar recht allgemein gehalten und kann auch genutzt werden, um andere Produkte herzustellen, ich mute mir hier aber keine Beurteilung zu, in welchen anderen Branchen dieses Konzept eingesetzt werden kann.

Noch ein paar Details?

Der Buchtext endet nach 178 Seiten. Danach folgt ein vierseitiges Literaturverzeichnis und der oben beschriebene Index mit Kurzfassungen, der 24 Seiten umfasst.