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.

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:

• Selbstverpflichtung (Commitment) - Einsatz zeigen, "für das Projekt brennen".
• Fokus - sich auf die aktuelle Aufgabe konzentrieren und nicht vom Projektumfang "erschlagen" lassen
• Offenheit - Probleme offen aussprechen und Hindernisse nicht schön reden oder verwalten sondern beseitigen.
• Respekt - Andere Mentalitäten, Arbeitsweisen und Know-How-Backgrounds akzeptieren und sie zum Vorteil des Projekts nutzen.
• Mut - Für die eigenen Ideen einstehen, seine eigene Meinung vertreten.

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:

• Product Owner - Definiert, was umzusetzen ist.
• Scrum Master - Ein Mediator, der Probleme beseitigt, das Team motiviert, antreibt und unterstützt. Die Rolle wird nicht als Leiter des Entwicklungs-Teams verstanden, weil Aufwandsabschätzungen, Entwicklungsgeschwindigkeit oder Umsetzungsweise rein dem Entwickler-Team überlassen sind. (Servant Leadership)
• Das Entwicklungs-Team - ein selbstorganisiertes Team, das die Anforderungen umsetzt und auch selbst entscheidet, wie sie umzusetzen sind. Das Team beinhaltet idealerweise funktionsübergreifende Mitglieder, so dass Know-How über alle Teile des Produkts vorhanden ist.

Folgende Artefakte sind in den Prozess involviert:

• Product Backlog - Umfasst alle Anforderungen an das Produkt und wird vom Product Owner gepflegt.
• Sprint Backlog - Anforderungen aus dem Product Backlog, die so genau spezifiziert wurden, dass sie umgesetzt werden können, werden in das Sprint Backlog aufgenommen und in einem Sprint (einer zeitlich begrenzten Entwicklungsperiode) abgearbeitet. Der Product Owner nimmt dabei die Priorisierung vor. Das Entwickler-Team entscheidet aber wie viele Anforderungen im Sprint umgesetzt werden.
• Inkrement - Das Ergebnis eines Entwicklungs-Sprints, eine Verbesserung bzw. Erweiterung des Produkts.
• Definition of done - Eine Spezifikation, die erfüllt sein muss, um eine Anforderung als abgearbeitet anzusehen.

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:

• Scrum ist bewusst kein befehlsgebendes System, weil das Entwicklungs-Team sich selbst organisiert. So werden Entwickler auch nicht zu Befehlsempfänger degradiert, sondern es bleibt Platz für Kreativität und Ideen. Das Entwicklungs-Team hat die Möglichkeiten, ein besseres Produkt zu realisieren, als es sich der Product Owner gedacht hat. Gleichzeitig steigt mit diesem Ansatz auch die Motivation im Team.
• Die Idee der inkrementellen Verbesserung liegt mir näher als einen großen Wurf nach einem langen Entwicklungs-Zyklus abzuliefern. Einer der Gründe, der auch im Buch erwähnt wird, ist ganz einfach, dass man als Entwickler immer eine andere Sicht auf das Produkt hat als der Kunde. Es ist daher wichtig den Kunden früh in ein Feedback-System einzubinden. Danach kann man das Produkt Schritt für Schritt verbessern. Außerdem ist es so viel leichter, auf Änderungen zu reagieren. Und Änderungen kommen immer und oft recht unerwartet.
• Die Sprint-Ziele und die Aufgaben im Sprint sind nicht abänderbar. Es ist wichtig, dass auch von der Seite der Auftraggeber innerhalb eines Entwicklungszyklus Anforderungen nicht geändert werden. Es kann dann nichts Brauchbares zu Stande kommen, wenn mitten in der Entwicklung Definitionen revidiert werden. Erst am Ende eines Sprints kann wieder über die weitere Vorgangsweise diskutiert werden.
• Das Entwicklungs-Team entscheidet selbst wie eine Anforderung umgesetzt wird. Ich hatte schon oftmals die Vorgabe mit einem suboptimalen System eine Funktionalität zu implementieren. Dies würde mit Scrum ausgeschlossen werden. (Man kann eine Baugrube mit einem Bagger oder mit einer Schaufel ausheben. Blöd wenn sich der Chef für die Schaufel entscheidet, aber schon am nächsten Tag das Ergebnis haben will.)

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.