Scrum / Wurden Agile’s Schwächen geerbt? Eine Antwort

Helene Valadon, eine unserer Consultants hat mich auf diesen höchst interessanten Post [1] aufmerksam gemacht. Das freut mich sehr, zeigt es doch klar welche Missverständnisse aufkommen können, wenn man nicht genug Erfahrung mit Scrum hat, bzw. wenn es an nötigem Wissen mangelt.

In dieser offenen Email möchte ich euch meine Antwort präsentieren.

Hi Chris,

Danke für deinen Post und dass du deine Erkenntnisse mit uns teilst. Ich schätze das sehr. Hier meine Antwort dazu.

> Scrum / Agile’s inherit shortcomings? [1]
> Posted by: “Chris Brookins” chris@… shippingnews
> Wed Feb 3, 2010 7:32 am (PST)
>
> Kürzlich bat mich mein CEO, eine Präsentation über Scrum’s geerbte Schwächen zu halten und eine Diskussion zu leiten, wie diese ausgebessert werden könnten.

Lasst uns mal darüber nachdenken, was Scrum ist, bevor es abgeändert und von einem Team entsprechend adaptiert wird. Wenn es sozusagen “frisch aus der Packung” kommt. Die Einsicht, gewonnen während der letzten paar Jahre, zeigt uns einige ernsthafte Schwächen auf.

1. Keine technischen Verfahren. Scrum eignet sich hervorragend dazu, Projektmanagement zu beraten, aber es liefert keine technische Unterstützung für den Entwickler. Jede fundierte Implementierung von Scrum erfordert geborgte technische Verfahren von anderen Methoden, wie etwa XP. Es ist zu empfehlen, eine technische Verfahrenslösung zu inkludieren. Zu empfehlen wären Lösungen wie: TDD,
Continuous Integration, Acceptance Testing, Pair Programming, Refactoring.

Dem kann ich nur völlig zustimmen und alle Scrum Trainer, mich eingeschlossen, haben das bereits erwähnt. Scrum’s primärer Zweck war und ist, Teams, Abteilungen und Firmen zu unterstützen, mit den Prinzipien von eigenständigen Arbeitsteams ihre Aufgaben zu bewältigen. Es war niemals geplant, Entwicklern beizubringen, wie man entwickelt. Wenn man Scrum implementiert, dann erkennt man schnell, dass die Entwickler nicht mit der Arbeitsweise von Agile vertraut sind.

2. Die 30-Tage Sprints sind zu lang. Viele Scrum Teams haben die Sprints auf 2 Wochen verkürzt, oder einen Zwischencheck nach 2 Wochen eingeführt. Ich weiß, dass einige Teams eine “2-Wochen-Wiederholung” in ihrem 4-Wochen Sprint eingeplant haben. Im Gegensatz zur herkömmlichen Methode dient der Sprint dazu, den offiziellen Report abzuliefern, während die Wiederholung wird für internes Feedback und Kontrolle benutzt wird.

Es wurde NIEMALS ausdrücklich gesagt, dass ein Sprint 30 Tage lang sein muss, sondern es war nur als Vorschlag gemeint. Ken und Jeff machten vor 15 Jahren mit den 30 Tagen große Fortschritte. Nicht mehr und nicht weniger. Sprints sollten so lange sein, wie es das Team und der PO für nötig halten und 2 Wochen werden oftmals vorgeschlagen. Allerdings verkompliziert sich dadurch die Sache für die meisten Entwickler.

3. Es besteht die Tendenz, dass der ScrumMaster sich ermächtigt, Befugnisse des Projektmanagement zu übernehmen. Das ist nicht so sehr das Problem des original Scrums, sondern entsteht vielmehr durch die Weiterentwicklung. Möglicherweise entsteht das Problem durch den Titel “Master” und es kann sein, dass der XP Titel “Coach” eher angebracht wäre. Bei einer guten Implementierung wird nicht notwendigerweise ein ScrumMaster einem Projektmanager gleichgesetzt.

Der ScrumMaster ist eine neue Führungsrolle. Ken hat dies vor Jahren geschrieben und für die ersten Scrum Experten, wie mich, war dies klar verständlich. Jedoch wollte dies die gesamte Agile Gemeinschaft nicht anerkennen, da es ihrem Verständnis nach nicht nötig war, dass Teams eine Führungskraft benötigen und Scrum eine neue Führungsrolle einnimmt. Ein ScrumMaster ist weder ein PM, noch ein Master des Teams. Er ist der Master innerhalb des Bezugssystems des Prozesses. Er ist der Leiter des Teams und der PO und es ist seine Aufgabe, die Organisation mittels Scrum zu verändern und Scrum als ein Paket von Tools und Grundwerten einzusetzen.

4. Das C in CSM ist eine unglückliche Wahl. Wiederum ist dies mehr ein Problem der Scrum Community, als das des Originals. Dem Buchstaben C wird viel zu viel Bedeutung beigemessen. Es versteht sich von selbst, dass ein Scrum Team trainiert werden muss und dazu gehört auch die Rolle des ScrumMasters. Problematisch ist, dass das C den ScrumMaster von einer Rolle zu einer tatsächlichen Persönlichkeit macht. Eine einzelne Person verfügt über das C. Idealerweise sollte die Rolle des ScrumMasters in einem Rotationssystem von jedem Teammitglied angenommen werden, so wie die Mitglieder eines XP Teams abwechselnd die Rolle des Coach einnehmen.

Es tut mir leid, aber das ist Unsinn. Ein Entwickler hat nicht die Fähigkeiten ein Team zu leiten, eine Organisation zu ändern und sein Team vor der herkömmlichen Organisationskultur zu beschützen. In dieser Hinsicht wird die Rolle des ScrumMasters großteils missverstanden. Er ist ein Moderator, aber das ist Teil seiner Führungsrolle als ScrumMaster. Ein ScrumMaster zu sein, das bedeutet, sich ein Set and Fähigkeiten anzueignen, die erlernt und geübt werden müssen. Dies kann 10000 Stunden in Anspruch nehmen, bevor man davon ausgehen kann, dass man diese Disziplin auch beherrscht.

Diese Rotation ist nicht immer perfekt und manchmal wird sie bevorzugt von ein oder zwei Personen eingenommen. Aber es war niemals geplant, dass eine bestimmte Person einen gewissen Rang verliehen bekommt und wir wollten das C nicht zu einem Wappenzeichen erheben.

Das C in CSM symolisiert keinen Rang. Es zertifiziert eine Person, die Kurse eines bekannten Scrum Experten besucht hat.

5. Die Anleitung hinsichtlich der Struktur von Backlogs ist bei Scrum mangelhaft. In den letzten Jahren haben wir erfahren, dass Backlogs hierarchische Einheiten sind, die aus Epics, Themes, Stories usw. bestehen und wir haben gelernt, sie statistisch zu bewerten. Wir haben außerdem gelernt, sie hierarchisch in höherrangige und niedrigrangige Einheiten zu unterteilen. Epics->Themes->Stories->Tasks.

Seltsam…das Erwähnte ist alles, was man dazu wissen muss. Mike Cohn hat uns das beigebracht und ich habe es in meinem Buch beschrieben. Scrum war nicht als ein Set von Tools geplant, das alles beschreiben kann. Der Backlog ist sehr unternehmens-/team-/produktspezifisch und Scrum kann in dieser Hinsicht keine Anleitungen liefern. Nur Best Practises können das. Diese können entweder Büchern entnommen werden, oder man tauscht sich mit Leuten aus, die Scrum verwendet haben. Natürlich ist es richtig, dass dieses Thema sehr wichtig für die meisten Organisationen ist. Insbesonders, weil sehr deutlich aufgezeigt wird, dass die meisten Produktmanager die Ausrichtung ihrer Produkte nicht kennen.

6. In Scrum versteckt sich eine Anti-Führungstendenz, die kontraproduktiv ist. Scrum konzentriert sich zu sehr auf die selbstleitende Rolle des Teams. Selbstorganisation und Selbstführung sind eine gute Sache, allerdings existieren Grenzen, was ein Team selbst entscheiden und tun kann. Teams müssen von jemandem geleitet werden, der für das Unternehmen veranwortlich ist und Scrum misst diesem nötigen Ausgleich nicht genug Bedeutung bei.

Ich stimme zu, dass die Marschrichtung für ein Team ganz klar von einer Führungskraft vorgegeben werden muss. Scrum bietet beides an: Der ScrumMaster, der die Richtlinien vorgibt innerhalb welcher ein Team arbeiten kann, und der ProductOwner, der das Team aus der Sicht des Unternehmers leitet.

7. Automatisierte Testverfahren. Das kann als Unterpunkt von Punkt 1 angesehen werden, aber ich denke, es ist aufgrund der Fundamentalität einer genaueren Betrachtung wert. Obwohl es ein Grundelement jeder Agile Unternehmung ist, wird es von Scrum nicht angesprochen. Agile Teams arbeiten in kurzen Zyklen, weil nur in diesen Feedback gut funktioniert. Kurze Zyklen alleine sind jedoch nicht genug, es bedarf auch einer objektiven Bewertung des gesamten Entwicklungsprozesses. Mit automatisierten Testverfahren, und indem man die erfolgreichen Tests festhält, kann man den Arbeitsfortschritt eines Teams am Besten beobachten.

Es ist nicht unbedingt fundamental. Vielmehr ist es eine Praxis aus dem Ingenieurswesen, die ein Team produktiver macht. Scrum zwingt Teams einen potentiell lieferbaren Code bei jedem Sprint zu liefern. TDD und automatisiertes Testen sind ein Ergebnis dieser Forderung von Scrum und keine Voraussetzung.

8. Mehrfache Teams. Scrum bringt nur wenig hinsichtlich der Koordination von mehreren, gleichzeitigen Teams. Allerdings ist dieser Mangel nicht alleinig ein Problem von Scrum. Auch Agile selbst hat wenig dazu zu sagen. Es gibt eine Erwähngung von “Scrum of Scrums”, doch diese Idee hat sich nicht wirklich durchgesetzt. Scrum im großen Stil scheint einigen wenigen Consultants vorbehalten zu sein, die angeblich eine Antwort parat haben, aber es gibt keinen Konsens zu diesem Thema.

Ich kann euch versichern, dass Scrum auch auf Ebenen oberhalb eines Teams erwiesenermaßen angewendet werden kann. Ich habe dies hunderte Male erfolgreich durchgeführt. Scrum Anwender wie ich haben Möglichkeiten entwickelt, Scrum in Organisationen einzusetzen, genauso wie auf Unternehmensebene. Gut, es wurde nicht in Ken’s erstem Buch beschrieben und viele Scrum Consultants haben keine Ahnung, wie das gemacht werden kann. Wenn ihr euch allerdings an Leute wendet, die Scrum seit 2003 einsetzen und Scrum auf Unternehmensebene angewandt haben, dann könnt ihr erfahren, wie das geht. Zu diesen Leuten gehören: Bas Voode, Mike Cohn, Stacia Broderick, Boris Gloger, Andreas Schliep, und viele mehr. Wie gesagt, man kann dazu nichts in den frühen Büchern finden, sondern in den Köpfen der Leute, die das bereits mehrmals gemacht haben.

Danke für deine anschauliche Kritik. Es beweist mir, dass wir Scrum weiterhing lehren, coachen und erklären müssen. Es ist ein langer Weg, der vor uns liegt…

Boris

[1] http://groups.yahoo.com/group/scrumdevelopment/message/44851