Agile Mythen: Scrum geht immer!

Viele Projekte die wir als Coach begleiten starten mit einem Kunden der uns anruft oder uns eine E-Mail schickt. In letzter Zeit lautet die Kernaussage meistens „wir wollen Scrum machen“ – mal mehr, mal weniger spezifisch ausgedrückt.

Als Agile Coach liegt der Schwerpunkt meiner Arbeit darin, Teams mit agilen Arbeitsweisen vertraut zu machen und in deren Umsetzung zu coachen. Dazu gehört für meine Kollegen und mich auch die Frage, ob Scrum für genau dieses Projekt und dieses Team das richtige Framework ist. Denn spätestens seit der Erfindung der User Story wissen wir, dass der Kunde wohl sehr gut beschreiben kann, welchen Nutzen er haben will, wir uns über das „wie kommen wir dort hin?“ aber durchaus noch unterhalten dürfen.

An dieser Stelle sei vorweg gegriffen: Scrum ist nicht immer das beste Mittel der Wahl!

Meine erste Frage lautet also: „Lieber Kunde, was braucht ihr denn?“ – und der zweite Satz lautet meistens: „Aha, und jetzt erzähl mir mal ein wenig darüber, was ihr macht und wie ihr bisher arbeitet“

Das einfachste Ausschlusskriterium zuerst:

Um die drei im Scrum-Framework definierten Rollen sauber besetzen und von einander trennen zu können, beziehungsweise ein vernünftiges Verhältnis zwischen den Rollen zu haben, empfiehlt sich Scrum nur für Entwicklungsteams ab 5 Personen. – Product Owner und Scrum Master noch nicht inklusive.

Ist dieses Kriterium erfüllt, wird es etwas komplizierter: Wir versuchen festzustellen, welches Framework am besten in die Situation des Kunden passt. Um einen ersten Überblick zu bekommen, wann welches agile Framework angebracht ist, orientieren wir uns dabei gerne an der Stacey-Matrix:

Je nachdem, wie weit Anforderungen an das Entwicklungsteam und die Lösungstechnologie zu beginn eines Projektes bekannt sind, lassen sich vier Arten von Projekten unterscheiden.

4 Projektarten

Bei einfachen Projekten sind Anforderungen und Lösungstechnologie  bekannt – weil wir zum Beispiel genau diesen Arbeitsschritt schon unzählige Male erledigt haben, lassen sich Aktivitäten sehr gut im Voraus planen. McDonalds baut die dreitausendste Fertigteil-Filiale auf eine grüne Wiese und kann ganz genau einplanen, nach wie vielen Tagen welcher Arbeitsschritt gefragt ist. Eine exakte Vorausplanung ist möglich, da ich meine Arbeitsschritte kenne. Reaktion auf äußere Änderungen ist eher unwahrscheinlich, ich kann die Planung typischerweise auch 1:1 von einem Projekt auf das andere übertragen. – bei diesen Projekten würden die Planungs- und Feedback-Schleifen die Scrum beinhaltet unnötigen Overhead darstellen. Scrum passt hier also nicht.

Das Gegenteil davon sind Projekte, in denen zu Projektbeginn weder Anforderungen noch Lösungswege bekannt sind – diesen Zustand nennen wir chaotisch. Dieser Zustand kommt Ihnen bekannt vor, falls Sie Bezug zur hypothesengesteuerten Grundlagenforschung haben. – Hierbei kann im Vorfeld beim besten Wissen und Gewissen keine Abschätzung getroffen werden, wie weit man nach einem vorher festgelegtem Takt von z.B. 2 Woche kommt. Das macht die Anwendung von Scrum ebenfalls schwierig – da gibt es besseres…

Sind Anforderungen oder Lösungstechnologie teilweise unklar, geht es im wesentlichen darum, den Durchsatz zu erhöhen. Stacey beschreibt diese Projekte als kompliziert. Beispiele hierfür sind Zeitungsredaktionen, Servicecenter oder Operations-Teams, die Debuggen. – In deren Anwendungsgebiet geht es in erster Linie weniger um die Produktoptimierung als um die Durchfluss-Optimierung; hier gibt es mit Kanban ein Framework, das besser die Bedürfnisse besser abdeckt als Scrum.

Und dann gibt es noch alles zwischen kompliziert und chaotisch. Dieser Bereich ist komplex. Komplexe Projekte haben schon erste Lösungshypothesen, alle Beteiligten wissen aber, dass sich die Hypothesen im Verlauf des Projekts noch in gewissem Umfang ändern dürfen. Dennoch können die Hypothesen schrittweise (also iterativ) erarbeitet werden und aufgrund des Feedbacks meiner Kunden erfahre ich, wo weitere Anpassungen erforderlich sind und wo nicht. – wir nähern uns von unserer aktuellen Position dem Eck links unten Schritt für Schritt. Genau dazu nutzen wir übrigens Scrum.

Stellen wir uns die Bereiche in denen Scrum nicht passt, anhand eines Beispiels vor

Optimierung des Durchsatzes mit Kanban

Nehmen wir das Beispiel einer Zeitungsredaktion. Zeitungsredaktionen arbeiten typischerweise zyklisch – Tageszeitungen in einem Tageszyklus, Wochenzeitungen in einem Wochenzyklus, etc.; Dank des Credos “nothing is as old as yesterdays newspaper” orientieren sich Redaktionen in erster Linie am Durchfluss. Der Ablauf eines Redaktionszyklus sieht in der Regel immer gleich aus, zum Beispiel wie folgt:

• Am Anfang gibt es eine Redaktionssitzung, in der das übergreifende Thema der Ausgabe und/oder die einzelnen Themen der kommenden Ausgabe besprochen werden. Am Ende gibt es eine (priorisierte) Liste an Artikeln, die in der kommenden Ausgabe erscheinen sollen.
• Nachdem alle Redakteure die Artikel besprochen haben, ziehen sich einzelne Teammitglieder Artikel, die sie bearbeiten möchten. In einem ersten Schritt gehen sie in eine Vorrecherche.
• In einem zweiten Schritt vereinbaren die Redakteure Expertengespräche oder Interviews. Dieser Schritt kann in einzelnen Fällen – zum Beispiel wenn es sich um ein Kommentar oder eine Glosse handelt – übersprungen werden.
• Danach wird der Artikel fertig gestellt.
• Während der Redakteur seinen Artikel geschrieben hat, hat ihm die Medienredaktion einen Vorschlag an passenden Bildern vorbereitet, aus der er nun eines auswählen kann. Der Verantwortliche der Medienredaktion war bei der Redaktionssitzung, kennt also das Thema des Artikels und grundlegende Eckpunkte, wie zum Beispiel Format und Größe des auszuwählenden Bildes.
• Ist beides zusammengeführt, gehen die Artikel ins Lektorat.
• Gibt das Lektorat sein okay, können die Artikel ins Layout gehen.

Der Lösungsweg ist immer der Selbe. Die Anforderungen (=Themen) ändern sich im Rahmen der Redaktion jedoch immer im Rahmen eines Spektrums. Folgt man der Stacey-Matrix ein klassisches Beispiel für Kanban – aber warum?

Die Artikel unterscheiden sich, Copy–Paste ist daher nicht möglich. Die Aufgabe ist nicht einfach.

Allerdings muss ich im Rahmen einer Redaktion in der Planung nicht ausführlich besprechen wie die Redakteure ihre Aufgaben lösen könnten. Auch die Aufgaben des Backlog Refinements, Themen vorbereiten und runter brechen, benötigen viel weniger bis garkeinen Raum. – Scrum erzeugt daher für dieses Szenario einen Overhead.

Das Ziel einer Redaktion ist es, den Durchfluss der Artikel zu optimieren; Kanban zeigt uns auf, wo in unserem Ablauf Engpässe entstehen. Zeigt mir mein Kanban-Board auf, dass sich Artikel z.B. vor dem Lektorat aufstauen, erkenne ich, dass es Sinn macht, Personen aus einem anderen Bereich der überdurchschnittlich gut abarbeitet, im Lektorat auszuhelfen.

Nicht alle Unternehmen schreiben Zeitungsartikel – Stimmt. Das Beispiel lässt sich aber 1:1 auf andere Aufgabenbereiche übertragen. Erfahrungsgemäß eignet sich Kanban unter anderem auch für Bereiche in denen der Durchfluss die wichtigste Messgröße ist, also zum Bug-Management oder für andere Bereiche, in denen heute mit Ticketing-Systemen gearbeitet wird.

Das andere Extrem: Ich habe keine Ahnung, wie mein Produkt aussehen kann.

2010 steht Steve Jobs vor einem ausgewählten Auditorium und erklärt, dass er sich gefragt hat, ob es Platz für irgendetwas zwischen Smartphone und Laptop gibt, ob Menschen etwas benötigen. Das war etwa 10 Minuten bevor CEO und Senior Manager festgestellt haben, dass sie sich ein iPad zulegen müssen, weil das genau DAS ist, was sie immer schon wollten. Steve Jobs beschreibt in dieser Präsentation auch, welche sieben grundlegende Ansprüche er an dieses potenzielle Produkt hatte.

„Als CEO oder Senior Manager möchte ich wissen, was ein neues Produkt, kleiner als ein Laptop aber größer als ein Handy, können muss, um zu… ja warum will ich das Ding denn überhaupt, wenn ich noch nicht weiß, was es können soll?“

Um diese Hypothesen zu formulieren und zu „vertesten“, eignen sich andere Frameworks erfahrungsgemäß besser als Scrum, zum Beispiel Design Thinking. Design Thinking nimmt die Hypothese, dass es ein Produkt kleiner Laptop und größer Smartphone brauchen könnte, versucht innerhalb kürzerster Zeit eine Reihe an Prototypen zu entwickeln und sammelt auf Basis dieser Erfahrungen Kundenfeedback.  Am Ende des Design Thinking Prozesses kennen Teams die für den Kunden wichtigsten Funktionalitäten.  Im Beispiel, dass es einen Markt für Produkte kleiner Laptop und größer Mobiltelefon gibt, stellt Steve Jobs diese im Video vor:

• “Browsing the Web”
• “Doing E-Mail”
• “Enjoying & Sharing Photographs”
• …

– Ich kann alle Scrum-Liebhaber an dieser Stelle allerdings vertrösten: Wenn Sie Ihre Hypothesen erstellt und an Ihrer Zielgruppe „verprobt“ haben und die Hypothesen stand gehalten haben, sind sie aus dem chaotischen Bereich raus; dann dürfen Sie weiter „scrummen“.