Agile Expert Talk #2: Scrum oder Kanban?

Lesen Sie hier den ersten Teil des Agile Expert Talks: Ohne agiles Mindset keine agile Organisation?

Im Ring für Scrum treten die drei Trainer-Schwergewichte Uta Kapp, Ralph Jocham und Marc Kaufmann an. Für Kanban steigt Markus Wissekal in den Ring. Letzter ist zwar in Unterzahl, aber was ihm an Personenstärke fehlt, macht er mit Flexibilität und Leidenschaft wett. Sebastian Friedsam und Marco Tommasone wollen sich als SAFe-Vertreter in der Runde keiner Seite eindeutig zuschlagen und übernehmen deshalb die Rolle der Ringrichter.

Wer die Diskussion gewonnen hat, entscheiden Sie selbst. Welche agile Projektmanagement-Methode überzeugt Sie mehr? Nutzen Sie gerne die Kommentare, um Ihre Stimme abzugeben und unseren Expertinnen und Experten Fragen zu stellen.

Bevor wir auf die Unterschiede von Scrum und Kanban zu sprechen kommen und teilweise auch einen Glaubenskrieg beschreiten, möchten wir fragen: Was ist beiden agilen Frameworks gemein?

Ralph Jocham: Aufbauend auf einem agilen Mindset, ist es die Einsicht, dass wir die Zukunft nicht vorhersehen können. Wir sind im Komplexen unterwegs und brauchen deshalb eine empirische Vorgehensweise. Alle agilen Vorgehensweisen, über die wir in dieser Runde sprechen sind in ihrem Herzen empirisch.

Sebastian Friedsam: Alle agilen Frameworks unterstützen auf ihre Art Feedbackzyklen. Es wird überprüft, was in einem gewissen Zeitraum gemacht wurde, um dann mit dem Feedback vom Auftraggeber bzw. den Kunden, die nächsten Schritte gehen zu können. Der gemeinsame Faktor ist in jedem Fall auch das agile Manifest. Die Frameworks unterscheiden sich im Endeffekt in der die Interpretation dieses Manifests.

Steigen wir ins erste Framework ein. Was ist Scrum für euch in wenigen Sätzen?

Marc Kaufmann: In der komplexen Welt ist mehr ungewiss als gewiss. Das Ungewisse in Scrum erkennen wir, indem wir kleine Schritte nach vorne machen. Kleine Schritte sind in Scrum sogenannte Inkremente, das heisst, fertige, auslieferbare Teile eines Produktes oder Services, die einen Wert schaffen. Dann validieren wir unsere Hypothesen, indem wir diese Inkremente an den Kunden ausliefern und Feedback einsammeln. Basierend auf dem Feedback lernen wir und passen uns an.

Die schnelle Anpassungsfähigkeit spielt bei agilen Projektmanagement-Methoden eine zentrale Rolle. Durch welche Vorgehensweisen in Scrum wird diese sichergestellt?

Marc Kaufmann: In Scrum passiert das durch ganz viele Feedbackschleifen im Team, sowohl für das Produkt, das sind die Sprint Reviews, als auch für den Prozess, das sind die Sprint-Retrospektiven.

Ralph Jocham: Ich möchte noch drei Wörter ergänzen: Transparency, Inspection, Adaptation. Das sind die drei Säulen auf denen die empirische Vorgehensweise in Scrum aufbaut. Wir brauchen Transparenz, damit wir inspizieren können: Wo sind wir? Wo wollten wir sein? Und die Inkremente, die wir laufend entwickeln und in der Sprint Review inspizieren, die geben uns diese Transparenz. Wir können sie unseren Kunden zeigen, Feedback einholen, darauf reagieren und adaptieren.

Uta Kapp: Und was in Scrum wunderbar funktioniert, ist, dass man eine Vision hat und sich dieser schrittweise annähert. Dabei kann man die Ziele auch mal verändern, ohne die Vision aus den Augen zu verlieren. Man schaut nicht erst nach vielen Monaten, wo man steht, sondern nähert sich in regelmässigen in Etappen dem Ziel an und kann frühzeitig feststellen, ob man noch auf dem richtigen Weg ist.

Sebastian Friedsam: Für mich bedeutet Scrum auch ein sehr aktives Risikomangement. Das hört sich zunächst kontrainduktiv an, aber was ist das Schlimmste das passieren kann? Das Schlimmste ist, dass ich feststelle, dass ich einen Sprint lang in eine andere Richtung gegangen bin und mit dem Learning die nächsten Schritte effizienter mache. Hier sehe ich die Stärke von agilen Methoden ganz allgemein. Scrum hat eine Timebox für das Risiko, Kanban hat ein Ticket für das Risiko.

Scrum wurde ursprünglich für die Softwareentwicklung konzipiert. Ralph, du sagst, Scrum eignet sich für alle komplexen Projekte in einer unvorhersehbaren Umwelt.

Ralph Jocham: Scrum ist 25 Jahre alt und hat vor langer Zeit die Softwareentwicklung verlassen. Ich hatte schon Rechtsanwälte bei mir im Training, die wollten ihre Kanzlei mit Scrum umsetzen. Auch aus dem Marketing habe ich regelmässig Teilnehmer. Wenn man sich heute den Scrum Guide anschaut, steht dort kein technisches Wort mehr drin. Scrum ist dafür da, komplexe Probleme zu lösen.

Wann sollten sich Unternehmen für Scrum oder Kanban erwärmen? Wann bieten sie eine vorteilhafte Methodik gegenüber dem klassischen Projektmanagement? 

Markus Wissekal: Man macht ja Scrum nicht zum Selbstzweck und Kanban-Boards, die nicht verwendet werden, die sterben in Schönheit. Wichtiger ist zu fragen: Was tun, wenn es nicht mehr so gut funktioniert, wie noch vor 5 oder 10 Jahren? Was hat sich am Markt verändert und wie kann ich mich mitverändern, wenn es darum geht für diesen Markt fit zu bleiben? Das startet manchmal mit ganz kleinen Schritten, die sehr oft darauf beruhen, mehr Feedback einzuholen und auch kürzere Feedback-Zyklen festzusetzen.

Ralph Jocham: Wenn ich nach klassischen und plangesteuerten Methoden arbeite, aber damit nicht mehr erfolgreich bin, dann habe ich wahrscheinlich die falsche Vorgehensweise gewählt und sollte empirisch arbeiten.

Sprechen wir über Kanban. Markus, du hast Kanban als eine alternative Methode zu Scrum beschrieben, die weniger Vorgaben macht und weniger starr ist. 

Markus Wissekal: Das kann man so interpretieren, muss man aber gar nicht. Mit Kanban stehe ich defacto eine Stufe über den anderen Frameworks. In Kanban gibt es sechs Grundpraktiken, von denen wir im Kanban-Umfeld sagen: Wenn du diese anwendest, wirst du erfolgreicher sein. Du wirst eine höhere Chance haben, dein Produkt oder deinen Service zu verbessern. Und wenn wir uns diese Praktiken genau ansehen, dann erkennen wir ganz klar, dass alle anderen agilen Frameworks, wie Scrum oder SAFe, spezifische Umsetzungen dieser Praktiken in sich tragen.

Welches sind diese sechs Kernpraktiken?

Markus Wissekal: Moderne Arbeit ist kreativ und passiert hauptsächlich im Kopf und ist deshalb unsichtbar. Damit wir erkennen, welche Last die anderen auf den Schultern tragen, heisst die erste Praktik, Arbeit sichtbar und damit transparent zu machen. Die zweite Praktik lautet: Fokussiere dich auf die wichtigen Dinge. Dafür schlägt Kanban bestimmte Methoden vor. Die dritte Praktik heisst: Manage aktiv den Fluss deiner Arbeit. Es gibt immer Situationen, wo etwas noch Wichtigeres auf den Tisch kommt. Und damit sind wir auch schon bei Kernpraktik Nummer vier: Mache implizite Regeln explizit. Damit wir als Team funktionieren, ist es beispielsweise wichtig, transparent zu machen, aus welchem Grund jemand mit seinem Thema auf der Überholspur vorbeifahren darf. Nummer 5: Schaffe Feedbackzyklen. Kanban gibt nicht vor, welche das sein sollen. Das wichtigste in Kanban ist, schaffe erst mal die Möglichkeiten, Feedback zu bekommen. Und als letzte Kernpraktik gilt: Verbessere dich gemeinsam. Nimm die Menschen mit, die diese Veränderung betrifft. Und verändere in kleinen Schritten, mit Experimenten die auch scheitern dürfen und vielleicht gerade zu Beginn kleiner definiert werden, damit sie – wenn es schon einen Einschlagskrater gibt – nicht gleich den eigen Kopf kosten.

Wäre es richtig zu behaupten, dass Kanban eine flexiblere Spielart einer agilen Methodik ist, die man an jedes Unternehmen oder jedes grosse Projekt vollkommen individuell anpassen kann? 

Uta Kapp: Wenn ich es mal genau nehme und diese Prinzipien zugrunde lege, dann kann man dann natürlich auch bei Scrum oder bei SAFe als Methode rauskommen. Die letzte wirklich radikale Hürde zu einem vollen Scrum ist dann nur noch der Sprint. Deshalb sehe ich das auch so, dass man Kanban über Scrum und SAFe platzieren kann.

Marco Tommasone: Für mich ist das spannende und charmante an Kaban, dass man dort starten kann, wo man ist. Du musst erstmal nichts verändern, sondern nur deine Arbeit visualisieren und transparent machen. Die Hürde, um loszulegen, ist bei Kanban weit runtergesetzt, während bei Scrum die Erwartungshaltung ist, es muss einen Scrum Master geben, es muss einen Product Owner geben und und und. An Kanban gefällt mir auch der sehr evolutionäre Ansatz. Wohin die Reise geht, das wird man unterwegs sehen. Es ist eben nicht ganz so radikal, was in vielen Situationen vielleicht zielführender zu sein scheint. Darin steckt aber auch eine Gefahr.

In welche Fallen kann man mit Kanban tappen?

Marco Tommasone: Alles hat seine Vor-und Nachteile. Der Vorteil von Scrum ist, dass es mit seinen Sprints und Events einen Rahmen vorgibt, an dem man sich leichter entlang hangeln und mit dem man schneller lernen kann, als mit Kanban, wenn es schlecht angeleitet wird. Ich habe mit ganz vielen Teams zu tun gehabt, die mir erzählt haben, dass sie mit Kanban arbeiten, aber wenn ich dann weiter nachgefragt habe, habe ich gemerkt: Nee, die haben nur bunte Zettel an der Wand, das ist nicht Kanban.

Wie kann Kanban funktionieren, wenn keine Rolle definiert ist, die über alle Zettel schaut und Vorgaben macht? Zum Beispiel, wie umfangreich und wie wichtig eine Aufgabe ist, die erledigt werden soll? 

Markus Wissekal: Kanban sagt nicht, dass es niemanden geben soll, der das macht. Im Gegenteil! Wir sagen in Kanban: Nutze zum Start, die Rollen, die es schon gibt. Und ich kenne keine Firma weltweit, wo es keinen gibt, der Priorisierung macht. Spannend ist doch, durch wen und wie. Und wenn man dann diese Personen, die Priorisierungen machen, hin zu den Menschen bringt, die die Arbeit umsetzen, dann passieren tolle Dinge.