5 Missverständnisse zu Scrum

Scrum ist einfach, aber nicht leicht“ heißt es in der agilen Community. Leicht zu verstehen, schwierig zu meistern. Und jeder, der sich auf den Weg gemacht, agil zu werden, weiß aus – meist nicht ganz schmerzfreier – Erfahrung, wie wahr das ist. Die wenigen Regeln, Rollen und Artefakte in Scrum suggerieren, dass das Agil-Werden und Agil-Sein eine recht simple Geschichte sei. Hier eine provokante Liste von „Irrtümern“, die wir zum Teil erlebt und glücklicherweise zum Teil vermieden haben.

 

Scrum-Projektmanagement-TechDivision

 

1. Wir machen Scrum, also sind wir agil.

Es war Martin Fowler, glaube ich, der einmal gesagt hat: „Man kann nicht agil sein nur mit Scrum.“ Agil sein heißt, beinah alles jederzeit ändern zu können, ohne dass man einen Zusammenbruch der Software, des Projekts oder des Projektteams zu befürchten hätte. Hat man nicht agile Softwareentwicklungs- und Management-Praktiken im Einsatz, hat man nicht automatisierte Tests auf mehreren Ebenen, eine emergente Architektur, gemeinsames Code Ownership im Team usw…: Dann kann man nicht agil sein. Das Scrum Framework als Fundament fördert nur die Schmerzen sehr schnell zutage. Es ist kein Sofort-Mittel gegen all diese Schmerzen.

 

2. In Scrum planen wir für die nächsten Sprints, nicht für eine weit entfernte Zukunft.

Bei Agile geht es nicht darum, keine Pläne zu haben. Es geht darum, Pläne zu haben und in der Lage zu sein, diese Pläne vollständig anzupassen, wann immer das nötig sein sollte. Hat mein kein „Big Picture“, keinen großen Plan, weiß man nicht, wo man hin will, und das ist in den meisten Fällen ein Problem. Um Jeff Patton zu zitieren: „Denken Sie meilenweit und zentimetertief.“ (Think milewide and inch deep). Wenn Sie keinen ein paar Zentimeter tiefen Plan für die nächsten sechs Monate haben, verlieren Sie leicht die Perspektive, und das ist nicht agil, sondern einfach nur gefährlich.

 

3. Die gängige RE Entität in Scrum ist die User Story: Als X will ich Y, damit Z.

Eine User Story ist das, plus die Konversation, die sich darum entspinnt, plus die Scribbles und Schmierereien auf dem Whiteboard währenddessen, plus die User-Akzeptanz-Kriterien, die das Ganze detaillieren. Hat man ein Backlog mit 50 Issues bestehend nur aus „Als X will ich Y, damit Z“, hat man ein großes Problem. Glaube Sie uns, wir haben es versucht.

 

4. Scrum bedeutet, iterativ und inkrementell ein komplexes System zu bauen

Es wird viel über Komplexität gesprochen im agilen Universum. Welche Komplexität? Die Komplexität des Systems oder die des Problemraums? Der Problemraum ist komplex (sonst bräuchte man keinen agilen Ansatz), das System dagegen sollte möglichst wenig komplex sein. Eventuell bedeutet ein komplexes Problem, dass auch das System komplex wird. Wenn es aber auch nur ansatzweise möglich ist, sollte das System nicht komplex sein. Um noch einmal Martin Fowler zu zitieren: „Sie werden es nicht brauchen“ (YAGNI, you aren’t gonna need it). Wenn man etwas in ein System einbaut, bei dem nicht 200% sicher ist, dass es umittelbaren Wert hat… sollte man es einfach nicht einbauen. Das ist nicht unproblematisch, weil es für Softwareentwickler eventuell weniger spannend und „sexy“ ist, nach diesem Prinzip vorzugehen. Doch darum geht es bei Scrum und Agile: Einfachheit. Die Kunst, die Menge nicht getaner Arbeit zu maximieren.

 

5. Scrum muss an die individuellen Gegebenheiten angepasst werden.

Das ist natürlich richtig. Die Ausgestaltung des Handelns innerhalb des Scrum-Frameworks muss an die individuellen Gegebenheiten angepasst werden. Inspect & adapt. Heißt das, dass Teile des Scrum-Frameworks verändert oder weggelassen werden können? Nein. Hand aufs Herz, das Scrum-Framework hat 3 Rollen, 3 Artefakte und fünf Events. Das ist eigentlich nicht besonders ausdifferenziert, überkomplex oder einengend. Wenn man es nicht schafft, diese 11 Gegebenheiten zumindest so lange zu realisieren, bis man die nötige Erfahrung, das Gespür, das Wissen hat, was man wie ändern kann, dann ist das ein grundlegendes Problem. Ein (sicher hinkender) Vergleich: Das Schachspiel hat nicht besonders viele Regeln. 5 Figuren, Rochade, Bauernverwandlung… Innerhalb dieses Regelwerks gibt es unendlich viele denkbare Schachpartien. Was passiert, wenn wir sagen, gut und schön, lasst uns Schach spielen, aber der König muss auch die Aufgaben der Dame übernehmen, der Läufer kann dafür ziehen wie ein Turm und 8 Bauern können wir uns nicht leisten, jeder kriegt nur 5 Bauern. Nun, dann ist es eben kein Schach. Man kann die Partien nicht mit Schachpartien vergleichen. Man darf sich nicht wundern „Ich weiß nicht, was die alle an Schach finden, so toll ist das doch gar nicht?“ Bevor man sich zutraut, ein neues Spiel zu erfinden, sollte man das zugrunde liegende Spiel beherrschen.

 

Und jetzt?

Natürlich kann und soll jeder machen, was er will. Was funktioniert. Wenn es funktioniert, ist egal, welchen Namen es trägt, oder?! Agile und Scrum sind keine Religionen. (Deshalb ist der Begriff „Evangelist“ eigentlich auch dumm, oder?) Jedoch ist Scrum ein mächtiger, durchdachter Ansatz, der es verdient, dass man ihn mit Herz und Verstand ausprobiert, wenn man das denn möchte. So schwierig das dann eben auch sein mag.

2 thoughts on “5 Missverständnisse zu Scrum

  1. Vielen Dank für den Artikel. Ich habe leider so gut wie nichts verstanden. Aber etwas gelernt. Schuster bleib bei Deinen Leisten. Ich werde auch nicht mehr versuchen eine Homepage zu erstellen, sondern es den Spezialisten überlassen. Und ich gehe wieder in meinen Garten und züchte Rosen und pflanze Gemüse. Das kann ich nämlich

Kommentar abgeben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.