Extreme Programming, Scrum, Kanban – was für wen?
Extreme Programming (XP), Scrum und Kanban sind die am weitesten verbreiteten agilen Methoden. Doch obwohl es sich bei allen drei um agile Methoden handelt, unterscheiden sie sich teilweise gravierend voneinander. Was sind die Gemeinsamkeiten, was die Unterschiede, und welche Methode eignet sich für wen?
- Golo Roden
Extreme Programming (XP), Scrum und Kanban sind die am weitesten verbreiteten agilen Methoden. Doch obwohl es sich bei allen drei um agile Methoden handelt, unterscheiden sie sich teilweise gravierend voneinander. Was sind die Gemeinsamkeiten, was die Unterschiede, und welche Methode eignet sich für wen?
Allen agilen Methoden als Grundlage gemein ist das Agile Manifest, das im Jahr 2001 unter anderem von Kent Beck, Martin Fowler und Robert C. Martin formuliert wurde. Es beschreibt im Wesentlichen vier Werte, die die Grundlage der agilen Denkart bilden. Alle diese Werte sind stets Aussagen, die zwei Aspekte gegenüberstellen, dem ersten dieser beiden Aspekte aber eine höhere Priorität einräumen. Die erste Aussage lautet:
"Individuals and Interaction over Processes and Tools."
Damit ist gemeint, dass Prozesse und Werkzeuge nicht unwichtig sind, aber die Bedürfnisse und Anforderungen der einzelnen Teammitglieder wichtiger sind als das Befolgen und Verwenden der Prozesse und Werkzeuge. Anders formuliert könnte man sagen, dass Prozesse und Werkzeuge dem Menschen dienlich sein sollen und nicht umgekehrt. Die zweite Aussage lautet:
"Working Software over Comprehensive Documentation."
Damit ist gemeint, dass funktionierende Software letztlich das Ergebnis von Softwareentwicklung sein sollte, und es im Zweifelsfall wichtiger ist, ebendiese Software in Händen zu hallten als eine umfangreiche, ausführliche Dokumentation. Letztere ist zwar nicht unwichtig, aber eben nicht so wichtig wie eine funktionierende Software. Die dritte Aussage lautet:
"Customer Collaboration over Contract Negotiation."
Auch hier ist die Aussage wieder, dass die Zusammenarbeit mit der Kundin oder dem Kunden auf Augenhöhe und auf partnerschaftliche Art wichtiger als das Aushandeln von Verträgen. Natürlich sollte eine Zusammenarbeit eine gewisse vertragliche Grundlage haben, aber diese sollte nicht im Vordergrund stehen und von vornherein darauf angelegt sein, dass man sich gegenseitig verklagen kann. Die vierte Aussage schließlich lautet:
"Responding to Change over Following a Plan."
Damit ist nicht gemeint, dass man nicht planen soll, sondern dass ein Plan eben nur genau das ist: Ein initialer Plan, der aber nicht in Stein gemeißelt sein sollte, komme was da wolle. Wenn es vernünftige Gründe gibt, einen Plan zu ändern, weil sich die Umstände geändert haben, ist es durchaus ratsam, genau das dann auch zu machen.
Gemeinsam haben all diese Formulierungen, dass eben die jeweils zweite Hälfte nicht als irrelevant angesehen wird, nur eben als nicht so wichtig wie die erste. Wer diese vier grundlegenden Werte beachtet und wertschätzt, hat eine gute Basis, um ein Projekt in dem Sinne umzusetzen, was man im Allgemeinen als "agil" bezeichnet.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Extreme Programming (XP)
Obwohl das Agile Manifest eine gute Basis darstellt, ist es doch wenig hilfreich im Sinne einer konkreten, praktischen Handlungsanweisung. Bereits in die erste Aussage lässt sich auf vielfältige Weise interpretieren, denn was genau bedeutet es, wenn man die Bedürfnisse und Anforderungen des Einzelnen höher wertet als das Befolgen von Prozessen und das Verwenden bestimmter Werkzeuge? Anders gefragt: Wie setzt man diesen Wert in die Praxis um?
Da es unterschiedliche Möglichkeiten gibt, diese Werte zu deuten, haben sich verschiedene Lesarten entwickelt, die schließlich in unterschiedliche agile Methoden gemündet sind. Eine davon ist das sogenannte Extreme Programming, das üblicherweise als "XP" abgekürzt wird, das seinerseits wiederum aus fünf Werten und einer Reihe von Regeln besteht.
Die fünf Werte sind Einfachheit, Kommunikation, Feedback, Respekt und Mut. Sie besagen, dass einfache Lösungen vorzuziehen sind, nicht nur in technischer, sondern auch in organisatorischer Hinsicht, und dass Kommunikation und Feedback essenziell für den Erfolg eines Teams sind – dass dabei aber zu beachten ist, dass man respektvoll miteinander umgeht, gleichzeitig aber auch Mut beweist, beispielsweise unangenehme Dinge anzusprechen.
Diese Werte legen beispielsweise nahe, dass gefundene Fehler proaktiv angesprochen werden sollten, dass dabei aber Kritik an der Sache und nicht an der Person geäußert werden sollte und dass die Kritik auch dann zu äußern ist, wenn es sich um den Code einer Vorgesetzten oder eines Vorgesetzten handelt. Es wird quasi eine gewisse Respektlosigkeit der Technologie gegenüber, aber Respekt dem Menschen gegenüber gefordert.
Die Regeln von Extreme Programming lassen sich ihrerseits wiederum in verschiedene Kategorien einteilen, und decken die gesamte Bandbreite der Softwareentwicklung ab – von der Projektplanung und -verwaltung, über das Entwerfen und Implementieren von Code bis hin zum Testen.
Tatsächlich erscheinen viele der Regeln von Extreme Programming heutzutage als Selbstverständlichkeit, beispielsweise ein iteratives Vorgehen, der Einsatz von Proof-of-Concepts und das konsequente Anwenden von Coding-Richtlinien und Unit-Tests.
Bemerkenswert an Extreme Programming ist, dass auch eine einzelne Entwicklerin oder ein einzelner Entwickler die meisten Praktiken anwenden kann, ohne dafür zuvor Einverständnis einholen oder das Team zur Mitwirkung auffordern zu müssen. Stattdessen kann man einfach loslegen und dazu beitragen, den Entwicklungsprozess auf organischem Wege zu verbessern.
Allerdings fehlt im Umkehrschluss die organisatorische Ebene in Extreme Programming weitgehend: Zwar gibt es einige Regeln für die Projektverwaltung, allzu viele sind das aber nicht, und zahlreiche Fragen bleiben offen. Insofern geht es bei Extreme Programming zwar nicht nur – wie der Name nahelegt – um das Schreiben von Code, trotzdem richtet sich die Methodik eher an technisch orientierte Mitarbeiterinnen und Mitarbeiter.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Scrum
Genau das Gegenteil ist in dieser Hinsicht Scrum. Es ist ein organisatorischer Rahmen, der Regeln für die Zusammenarbeit in einem Team vorgibt, Scrum sagt jedoch nichts darüber aus, wie die tatsächliche Arbeit auszuführen ist. Theoretisch lässt es sich daher auch in anderen Domänen als der Softwareentwicklung anwenden, man könnte beispielsweise auch einen Hausbau mit Scrum umsetzen.
Grundsätzlich definiert Scrum zunächst drei Rollen. Während die "Product-Ownerin" oder der "Product-Owner" die fachliche Seite vertritt, obliegt die technische Umsetzung dem "Team". Dieses besteht aus idealerweise sieben Personen, wobei diese alle Rollen umfassen sollen, die für die Umsetzung eines Projekts erforderlich sind.
Ein Team besteht also nicht nur aus Entwicklerinnen und Entwicklern, sondern umfasst auch Personen mit anderen Fähigkeiten und Kenntnissen. Zu guter Letzt gibt es noch die "Scrum-Masterin" beziehungsweise den "Scrum-Master", deren beziehungsweise dessen Aufgabe es ist, auf die Einhaltung der Regeln von allen Beteiligten zu achten.
Die Ausgangsbasis für die Arbeit mit Scrum stellt das sogenannte Backlog dar, das die fachlichen Anforderungen in Form sogenannter User-Stories enthält. Eine User-Story stellt dabei eine kurze Beschreibung des zu entwickelnden Features oder des zu behebenden Fehlers dar, enthält aber nicht nur die Beschreibung an sich, sondern darüber hinaus häufig auch die Informationen, welchen Geschäftswert die Umsetzung dieser Story liefert. Auf dem Weg soll sichergestellt werden, dass Stories keinen Selbstzweck darstellen, sondern stets einem höheren Ziel dienen.
Die Abarbeitung dieses Backlogs erfolgt bei Scrum iterativ in sogenannten Sprints, die Zeiträume von üblicherweise ein bis vier Wochen darstellen, wobei kürzere Sprints zu bevorzugen sind. Zu Beginn eines Sprints entscheidet das Team in gemeinsamer Abstimmung mit der Product-Ownerin beziehungsweise dem Product-Owner, welche Stories angegangen werden sollen. Während des Sprints trifft man sich täglich zu einem Meeting, dem Daily, um über den aktuellen Fortschritt und eventuell aufgetretene Hindernisse und Probleme zu sprechen.
Am Ende eines jeden Sprints gibt es zunächst einen Review, bei dem das Team die erfolgreichen umgesetzten Stories präsentiert, das zugleich auch als fachliche Abnahme dient; und anschließend eine Retrospektive, in der über die Arbeit auf der Metaebene gesprochen wird: Was lief gut? Was lief schlecht? Was sollte an der Art der Zusammenarbeit beibehalten, geändert oder verworfen werden?
Das Team misst außerdem die Geschwindigkeit, mit der es vorangekommen ist, um auf dieser Basis nach und nach eine bessere Ausgangsbasis für verlässliche Schätzungen zu entwickeln. Diese Geschwindigkeit, die in Scrum als Velocity bezeichnet wird, basiert häufig auf Punktwerten und nicht auf tatsächlichen Zeiteinheiten, um bewusst nicht über Zeit, sondern über Komplexität der Stories zu sprechen.
Ein wesentlicher Kritikpunkt an Scrum (oder besser gesagt der üblichen Anwendung von Scrum) besteht darin, dass Teams sich zu häufig dem Sprintziel verpflichten, also der initial für einen Sprint geplanten Menge an User-Stories. Wird dieses Ziel nicht erreicht, sorgt das häufig für entweder schlechte Stimmung, für minderwertige Qualität auf Grund von Zeitdruck oder im schlimmsten Fall für beides. An der Stelle ist Scrum leider nicht eindeutig genug und rückt die Qualität nicht ausreichend in den Vordergrund.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Kanban
Um diesem Problem zu begegnen, gibt es Kanban. Diese agile Methode geht auf die Lean-Production aus dem Automobilbau zurück, konkret auf Toyota. Das Wort "kan" bedeutet im japanischen "Signal", "ban" bedeutet "Karte".
Die grundlegende Idee von Kanban ist die eines gemeinsamen Kanban-Boards, das in mehrere Spalten unterteilt wird, beispielsweise für die noch zu erledigenden Aufgaben, für die derzeit in Bearbeitung befindlichen Aufgaben, für die zu testenden Aufgaben, und für die bereits erledigten Aufgaben. Die einzelnen Aufgaben wiederum werden auf Karten notiert, die nach und nach von links nach rechts auf dem Board verschoben werden – je nach Fortschritt.
Das Besondere an Kanban ist nun, dass diese Spalten in ihrer Kapazität limitiert werden. Das heißt, dass beispielsweise in der Spalte für die zu testenden Aufgaben nur eine begrenzte Menge an Karten untergebracht werden darf. Das ist sinnvoll, da auch in der Realität nur begrenzte Testkapazitäten zur Verfügung stehen, was auf dem Weg auch auf dem Kanban-Board abgebildet wird.
Das Ziel ist, Engpässe und Verzögerungen zeitnah identifizieren und im Idealfall beheben zu können, um einen möglichst gleichmäßigen und stetigen Strom von Karten zu ermöglichen, ohne dass der Prozess dabei ins Stocken gerät. Anders als Scrum setzt Kanban also nicht auf immer wiederkehrende Iterationen, sondern eher auf einen kontinuierlichen Fluss.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Welche agile Methode für wen?
Insgesamt stellt sich nun die Frage, welche agile Methode sich für wen eignet. Tatsächlich handelt es sich hierbei gar nicht so sehr um eine Entweder-Oder-Frage, wie man zunächst meinen könnte, da sich Extreme Programming, Scrum und Kanban nicht notwendigerweise gegenseitig ausschließen. So lässt sich insbesondere Extreme Programming hervorragend mit einer der anderen beiden Methoden kombinieren, weshalb man in der Praxis häufig auf XP + Scrum beziehungsweise XP + Kanban trifft, häufig jedoch nicht in Reinkultur nach dem Lehrbuch, sondern in einer individuell adaptierten Variante.
Prinzipiell spricht auch gar nichts dagegen, eine oder mehrere agile Methoden gemäß den individuellen Anforderungen und Bedürfnissen anzupassen – denn genau das entspricht der ersten Aussage des Agilen Manifests, und auch Extreme Programming, Scrum und Kanban sind letztlich nichts anderes als Prozesse, die einen Zweck erfüllen sollen, sie sind keinesfalls ein Selbstzweck.
Trotzdem gilt es dabei natürlich aufzupassen, dass man nicht die essenziellen Bausteine derart verändert, dass die gewünschten Effekte nicht mehr eintreten. In der Praxis begegnet man häufig Unternehmen, die insbesondere Scrum "nach Art des Hauses" umsetzen und sich zugleich darüber beklagen, dass sie die Vorteile, die Scrum verspricht, in ihrer eigenen Arbeit nicht sehen würden. Daher ist es im Zweifelsfall ratsam, sich zunächst am Lehrbuch zu orientieren, bevor man eigene Experimente wagt.
Ob man nun letztlich Scrum oder Kanban favorisiert, ist vermutlich zumindest im Bereich der Softwareentwicklung zu einem großen Teil eine Frage der persönlichen Präferenzen. Eine pauschale Empfehlung kann es hier nicht geben, doch bieten beide Methoden zunächst eine gute Ausgangsbasis, um agil zu entwickeln. Der Einsatz von Extreme Programming ist so oder so eine durchaus empfehlenswerte Idee, was insbesondere dadurch, dass auch einzelne Entwicklerinnen und Entwickler XP weitestgehend umsetzen können, befördert wird.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Fazit
Der Einsatz von agilen Methoden ist aus der modernen Softwareentwicklung kaum mehr wegzudenken. Egal, für welche agile Methode man sich letztlich entscheidet – langfristig wird man vermutlich in jedem Fall Anpassungen an die eigenen Bedürfnisse und Anforderungen vornehmen.
Trotzdem ist es ratsam, zunächst eher nah am Lehrbuch zu starten, um sich dem Thema überhaupt erst einmal zu nähern und die versprochenen Effekte in der Praxis auch tatsächlich erreichen und erzielen zu können.
Wenn man dann nach einer Weile Erfahrung in einer oder im Idealfall in mehreren agilen Methoden gesammelt hat, steht einer Adaption nichts mehr im Wege. ()
