Es ist fast 10 Jahre her, seit ich angefangen habe, mit Agile zu arbeiten. Ich erinnere mich, dass meine erste Erfahrung war, als ich in Suedfrankreich fuer Amadeus arbeitete. Damals schlug das Management des Unternehmens vor, die Arbeitsweise der Entwicklungsteams zu aendern und zu aktualisieren und eine Einfuehrung agiler Methodologien durchzufuehren, hauptsaechlich unter Verwendung des Scrum-Frameworks. In meinem Team bot man mir eine Scrum-Master-Schulung an, die 3 Tage dauerte, danach musste ich eine Pruefung ablegen, um zertifiziert zu werden. Und so wurde ich ein zertifizierter Scrum Master.

Seitdem hatte ich die Gelegenheit, mit Scrum in 3 Unternehmen und 8 verschiedenen Teams zu arbeiten, Projekte abzuschliessen und Produkte fuer sehr unterschiedliche Zwecke zu entwickeln. Allerdings blieb ein gemischtes Gefuehl zurueck. Einerseits glaube ich, dass Scrums Idee, Arbeit in kleine Iterationen aufzuteilen und haeufig Versionen zu veroeffentlichen, damit Kunden sie testen und Feedback geben koennen, uns viel gebracht hat. Aber andererseits habe ich ziemlich oft gesehen, wie sich die Teamproduktivitaet verschlechterte, und ich hatte nicht das Gefuehl, dass uns das Framework die Werkzeuge gab, um die Situation zu bewaeltigen. Ausserdem fuehlte sich seine stark vorschreibende Natur manchmal etwas starr an, um unsere Probleme zu loesen.

In den letzten Jahren habe ich auch mit Teams gearbeitet, die Kanban fuer den Betrieb und Scrumban fuer die Entwicklung verwendeten, aber wie bei Scrum hatte ich nicht das Gefuehl, dass sie den gesamten erwarteten Wert lieferten.

Aus diesen Gruenden habe ich mich entschieden, die gaengigsten agilen Frameworks und Methodologien erneut zu betrachten, um zu versuchen zu verstehen, 1) was die Philosophie und die Schluesselideen hinter jedem von ihnen sind und 2) welche moeglichen Defizite oder Fehler bei der Implementierung in unseren Teams begangen wurden. Aber ich moechte vorwegnehmen, dass dieser Beitrag nicht den Anspruch hat, die verschiedenen Methodologien und ihre Probleme vollstaendig zu beschreiben, sondern eher ein Kompendium von Ideen und Erfahrungen sein soll, das als Ausgangspunkt dient, um die uns interessierende Methodologie detaillierter zu erforschen. Dafuer sind die Referenzen am Ende des Beitrags sehr empfehlenswert.

Ich habe mich auf 4 agile Werkzeuge, Methodologien oder Frameworks konzentriert: Extreme Programming, Scrum, Kanban und Scrumban, da sie die bekanntesten in der Softwareindustrie sind. Aber zunaechst moechte ich am Anfang beginnen: dem Agile Manifest.

Agile Manifest

Es entstand am Wochenende vom 11. bis 13. Februar 2001, als eine Gruppe von Software-Ingenieuren, darunter Martin Fowler, Robert C. Martin, Kent Beck oder Jeff Sutherland, unter anderen, sich in einem Skigebiet in den Bergen von Utah trafen, um zu reden und zu versuchen, einen gemeinsamen Rahmen zu finden, der ausdrueckte, wie sie Softwareentwicklung sahen. Es entstand als Reaktion auf das vorherrschende Modell bis zu diesem Zeitpunkt, das auf lange, durch umfangreiche Dokumentation getriebene Prozesse setzte. Sein Hauptziel war es, die Menschen wieder in den Mittelpunkt zu ruecken, die in den grossen buerokratisierten Organisationen der damaligen Zeit in den Hintergrund gedraengt worden waren. Die Versammelten wollten die Werte und Prinzipien einer neuen “kulturellen” Bewegung definieren, die dazu dienen sollte, Gemeinschaften und Organisationen zu schaffen, in denen sie das Gefuehl hatten, arbeiten zu wollen.

agilemanifesto.org

Beim erneuten Lesen des Manifests fallen mir Situationen ein, in denen wir selbst bei der Arbeit mit agilen Frameworks dem Manifest nicht treu waren. Ich erinnere mich an einen Fall, der den Wert der Priorisierung gut repraesentiert: “Zusammenarbeit mit dem Kunden ueber Vertragsverhandlung.” Vor einigen Jahren mussten wir in einem Projekt, das wir mit einem Scrum-Team durchfuehrten, eine Funktionalitaet entwickeln, die vertraglich zugesagt worden war, obwohl der Kunde uns spaeter (bei einem der woechentlichen Meetings) mitgeteilt hatte, dass er sie nicht nutzen wuerde. Trotzdem bat uns das Vertriebsteam, sie zu implementieren, um den Vertrag nicht zu verletzen. Rueckblickend und mit dem Manifest vor uns betrachtet, glaube ich, dass der angemessene Weg gewesen waere, agile Prinzipien auch bei der Vertragsgestaltung anzuwenden. Wir koennten weiterhin Funktionalitaeten in den Vertrag aufnehmen, aber eine Klausel hinzufuegen, nach der diese Funktionalitaeten gegen andere (aehnlicher Kosten) mit vorheriger Zustimmung beider Parteien getauscht werden koennten.

Dies ist nur ein Beispiel dafuer, wie die agile Philosophie weit ueber die Organisation der Teamarbeit hinausgeht und einen Wandel der Denkweise und Arbeitsweise fuer die gesamte Organisation erfordert. Deshalb muss ein Unternehmen, das eine agile Transformation durchfuehren will, verstehen, dass dies einen Kultur- und Arbeitswandel in vielen seiner Abteilungen bedeutet, nicht nur in den Entwicklungsteams. Aus dieser Perspektive ist leicht einzusehen, dass die Bezahlung eines Scrum-Master-Kurses fuer Entwickler kaum ausreichen wird, um diese agile Transformation im gesamten Unternehmen durchzufuehren.

Ein weiterer Punkt, der erwaehnenswert erscheint, ist der, der sagt: “(wir schaetzen) Individuen und Interaktionen mehr als Prozesse und Werkzeuge.” Ich habe das Gefuehl, dass agile Frameworks und Methodologien oft mechanisch befolgt werden, Kaestchen auf einer Checkliste ankreuzend, ignorierend, dass sie Werkzeuge im Dienste der Menschen sein sollten und nicht umgekehrt.

Ich moechte mich zu diesem Punkt nicht weiter ausdehnen, aber ich empfehle Ihnen, die Manifest-Seite zu besuchen und es sorgfaeltig zu lesen. Ich bin sicher, es wird als Spiegel dienen, um zu sehen, wie Sie mit Agile arbeiten und ob es Dinge in Ihrer aktuellen Arbeitsweise gibt, die Sie nach agilen Prinzipien ueberdenken koennen.

Extreme Programming

Es ist eine Softwareentwicklungsphilosophie, die von Kent Beck Ende der 90er Jahre entwickelt wurde und 1999 mit seinem Buch Extreme Programming Explained oeffentlich wurde. Man koennte sagen, es dient dazu, (zusammen mit anderen bestehenden Methodologien) das Agile Manifest zu inspirieren, das die agile Bewegung ausloest. Der Autor sagt, er waehlt das Adjektiv extrem, weil er denkt, dass man, um Qualitaetssoftware zu entwickeln, Programmierpraktiken bis zum Aeussersten oder ihrem reinsten Ausdruck treiben muss. Eine dieser Praktiken, die er vorschreibt, ist Pair Programming, das seiner Meinung nach fuer die Programmierung des gesamten Produktionscodes verwendet werden sollte (was mir persoenlich ziemlich extrem erscheint).

Beck sagt, XP sei ein Versuch, Menschlichkeit und Produktivitaet in der Softwareentwicklungspraxis zu vereinen. Und er drueckt aus, dass er festgestellt hat, dass man umso produktiver wird, je menschlicher man sich selbst und andere behandelt. Er plaediert dafuer, zu akzeptieren, dass Programmierer Menschen in einem Geschaeft zwischen Menschen sind, und flieht vor den vorherrschenden Ideen in Organisationen, die Entwickler als Teile eines komplexen, der Menschlichkeit beraubten Getriebes behandelten.

Die XP-Philosophie fuehrt eine Reihe von Werten, Prinzipien und empfohlenen Praktiken fuer die Softwareentwicklung ein. Und viele neue Ideen, die den damals vorherrschenden Prozessen, hauptsaechlich Waterfall, entgegenstanden. Zu den wichtigsten gehoeren das Arbeiten in kleinen Iterationen oder das haeufige Anhoeren von Kundenfeedback waehrend der Entwicklung. Sie empfiehlt auch, dass Entwickler die meiste Zeit zu zweit programmieren (Pair Programming) oder die Entwicklung mit Tests beginnen (Tests first). Sie fuehrt auch Konzepte wie Continuous Integration oder 10-Minuten-Builds ein (wir sprechen von 1999), die als Industriestandards uebernommen wurden.

Ron Jeffries — The Circle of Life: XP Practices

Diese Praktiken und Prinzipien basieren auf den Werten Kommunikation, Feedback, Einfachheit, Mut und Respekt. Die letzten beiden Werte konzentrieren sich auf das Individuum. Einerseits wird kommentiert, dass man den Mut haben muss, gute Arbeit zu leisten, Erfolg zu suchen und mit den Konsequenzen umzugehen (dies ist das, was Beck auch als extrem beschreibt). Und andererseits muessen Individuen in einem Team genuegend gegenseitigen Respekt mit allen Stakeholdern haben und Offenheit, neue Arbeitsweisen auszuprobieren, wenn es der Wille des Teams ist.

Eine wichtige Idee ist, dass Praktiken in Prinzipien und Werten verankert sein muessen. Man muss verstehen, warum wir einer Praxis folgen; wenn der Grund ist, dass sie von Managern auferlegt wird, werden sie laestig und anfaellig dafuer, nicht korrekt durchgefuehrt oder vermieden zu werden. Persoenlich glaube ich, dass die Person, die Praktiken einfuehrt, den neuen Teammitgliedern die Motivation fuer die Verwendung dieser Praxis erklaeren sollte, dann die Adoption der Praxis verfolgen und den Wert hervorheben sollte, der erzielt wird, wenn neue Mitglieder sie zu nutzen beginnen. Erst wenn wir eine Praxis nutzen und aus erster Hand den Wert sehen, den sie uns bringt, haben wir die notwendigen Informationen, um sie zu akzeptieren und in unsere Arbeitsweise zu integrieren.

Ein weiterer wichtiger Punkt ist, Praktiken und das, was sie uns bringen, wirklich zu verstehen. So vermeiden wir, die Praxis unvollstaendig zu implementieren oder sie durch eine zu ersetzen, die aehnlich erscheint, es aber nicht ist. Dies geschieht zum Beispiel, wenn wir Test Driven Development (TDD) durch Unit Testing ersetzen. Im Test Driven Development ist vorgeschrieben, zuerst Tests zu schreiben, sie auszufuehren, um zu sehen, wie sie fehlschlagen, und dann Anwendungscode zu schreiben, bis alle Tests erfolgreich bestanden werden, und in diesem Moment aufzuhoeren (TDD schreibt vor, dass wir nur den Code schreiben sollen, der notwendig ist, um alle Tests zu bestehen). Auf diese Weise werden Tests zum Mechanismus, um zu erkennen, wann wir eine Funktionalitaet abgeschlossen haben und aufhoeren koennen zu programmieren, zusaetzlich dazu, dass sie uns zwingen, die Code-Architektur testbar zu gestalten. Wenn wir jedoch nur Unit Tests schreiben, nachdem wir die Funktionalitaet fertig programmiert haben, dient der Test nicht mehr dazu, das Programmieren der Funktionalitaet zu leiten, sondern sein Wert reduziert sich auf das Testen der Funktionalitaet. Ausserdem ist auf diese Weise die Funktionalitaet bereits programmiert, sodass wir in unserem Kopf das Gefuehl haben, fertig zu sein, obwohl wir noch die laestige Formalitaet der Unit Tests erfuellen muessen.

Persoenlich kenne ich niemanden, der mit Extreme Programming in seinem umfassendsten Ausdruck arbeitet, und ich habe auch nicht den Eindruck, dass viele Unternehmen dies heutzutage tun (ich habe eine schnelle Suche auf LinkedIn gemacht und nur 30 Stellenangebote in Spanien enthalten die Worte Extreme Programming gegenueber mehr als 6000, die das Wort Scrum enthalten). Dennoch glaube ich, dass Extreme Programming eine sehr interessante Quelle von Praktiken und Prinzipien ist, die in jeder der anderen agilen Methodologien angewendet werden koennen; tatsaechlich werden viele bereits verwendet, wenn wir beispielsweise in Scrum arbeiten. Im Gegensatz zu anderen Werkzeugen, die eher wie Rezepte zum Befolgen funktionieren, vertieft sich XP in Motive und Gruende, was uns mehr Ressourcen gibt, um robuste Entscheidungen zu treffen, die unsere Arbeitsweise beeinflussen.

Scrum

Es ist eines der populaersten agilen Frameworks in der Softwareentwicklungsindustrie, obwohl es nicht mehr spezifisch fuer Software ist, sondern in verschiedenen Branchen eingesetzt wird. Es erschien 1995 und wird als eine Art der Teamarbeit definiert, genauer gesagt in kleinen multidisziplinaeren und selbstverwalteten Teams, in denen man an kleinen Aufgaben mit kurzen Entwicklungszyklen (genannt Sprints) arbeitet, an deren Ende man ein potenziell lieferbares Funktionalitaets-Inkrement erhaelt.

Es ist ein empirischer Prozess, der auf 3 Saeulen basiert: Transparenz, Inspektion und Anpassung, die sich folgendermassen manifestieren: Der Prozess und der Status der laufenden Arbeit sind fuer das Team und andere Stakeholder sichtbar (Transparenzprinzip), dies ermoeglicht die Inspektion des Fortschritts in Bezug auf die gesetzten Ziele (Inspektionsprinzip) und die Anpassung/Kurskorrektur bei Abweichungen (Anpassungsprinzip). Diese Anpassung ist ein Ergebnis der kontinuierlichen Verbesserung, die Teams durchfuehren muessen.

Scrum.org: Scrum-Werte

Obwohl es viele Projektmanagement-Praktiken mit XP teilt, schreibt es keine technische Praxis oder kein technisches Prinzip vor und praesentiert natuerlich keine spezifische Philosophie darueber, wie man ein Entwickler sein sollte. Dieser Mangel an Vorschrift technischer Prinzipien und Praktiken hat viele fehlerhafte Implementierungen verursacht und verursacht sie weiterhin, bei denen die technische Schuld des Projekts weiter waechst und einen Rueckgang der Teamproduktivitaet verursacht, wie Martin Fowler bereits 2009 in seinem Artikel Flaccid Scrum kommentierte.

Das Framework schreibt eine Reihe von Rollen vor: Scrum Master, Product Owner und Developers. Der Product Owner ist verantwortlich fuer die Produktvision und das Ziel. Er ist auch derjenige, der User Stories definiert und sie im Backlog priorisiert. Der Scrum Master ist der Prozessgarant, derjenige, der das Team schult, Hindernisse beseitigt und moderiert, unter anderem. Und dann sind die Developers diejenigen, die die Arbeit planen und ausfuehren und dabei deren Qualitaet und Konformitaet mit den Sprint-Zielen gewaehrleisten. Eines der Probleme, auf die ich haeufig gestossen bin, ist, dass Personen, die die Rollen von Product Owner und Scrum Master ausfuellen, andere Verantwortlichkeiten ausserhalb von Scrum haben, was dazu fuehrt, dass sie oft zu Engpaessen werden, die die Teamproduktivitaet beeintraechtigen. Ein typischer Fall ist ein Product Owner, der aus Zeitmangel keine Akzeptanzkriterien in User Stories definiert, was Entwickler dazu zwingt, bereits geschlossene User Stories erneut zu besuchen, um sie zu vervollstaendigen, mit der daraus resultierenden Frustration von Kunden und Entwicklern selbst.

Ein weiteres haeufiges Problem ist das Fehlen einer Definition of Done oder deren Nichteinhaltung. Die Definition of Done sind allgemeine Kriterien, die eine Aufgabe erfuellen muss, um geschlossen zu werden. Zum Beispiel: ein Code Review durch 2 Personen durchgefuehrt zu haben, neue Unit Tests hinzugefuegt/modifiziert zu haben und Code-Branches in den Integrationsbranch gemerged zu haben. Aus meiner persoenlichen Erfahrung ist die Definition of Done etwas, das von den Entwicklern kommen muss. Es ist wichtig, dass mindestens ein Entwickler im Team (idealerweise mehr) den Bedarf und den Wert versteht, den sie bringt. Wenn die Definition of Done vom Manager definiert wird, aber innerhalb des Teams keine Ueberzeugung von ihrem Wert besteht, ist es am wahrscheinlichsten, dass sie bei der ersten Gelegenheit ignoriert wird und in Vergessenheit geraet.

Unter den Zeremonien, die das Framework vorschreibt, ist eine der laengsten das Sprint Planning, das darauf abzielt, dass das Team die vom Product Owner priorisierten User Stories ueberprueft, sie schaetzt und zuweist, bis die Kapazitaet fuer diesen Sprint ausgefuellt ist. Ohne Zweifel ist die laengste Aufgabe die Schaetzung von User Stories, bei der das gesamte Team darueber spricht, wie die Story in Unteraufgaben aufgeteilt werden kann, und technische und Implementierungsaspekte diskutiert werden, um dann in Story Points zu schaetzen. Manchmal habe ich gesehen, wie eine einzelne User Story eine Stunde zur Schaetzung brauchte. In einem Team von 8 Personen sind das 8 Stunden nur fuer die Schaetzung einer Story. Es stimmt, dass die Uebung des sorgfaeltigen Schaetzens als Team erlaubt, mit der Gestaltung der Story-Implementierung zu beginnen, und Input von mehreren Personen neue Gesichtspunkte bietet und es ermoeglicht, Probleme und potenzielle Schwierigkeiten vorherzusehen, aber aus meiner Sicht ist es zu teuer. Ganz zu schweigen davon, dass oft nur 2 oder 3 Personen teilnehmen, waehrend der Rest schweigt und sich oft abkoppelt, was in der Regel demotivierend wirkt.

Meiner Meinung nach kann Scrum ein interessantes Framework fuer Teams sein, die mit der Entwicklung eines neuen Projekts/Produkts beginnen und noch keine effiziente Arbeitsweise haben. Aber von Anfang an muessen technische Praktiken definiert werden, die das gesamte Team versteht und befolgt, wobei man sich sehr bewusst sein muss, dass technische Schulden immer lauern werden. Ich wuerde auch besonderen Wert auf die Visualisierung des Arbeitsflusses legen, indem ich ein Kanban-Board verwende (vorzugsweise physisch, und wenn nicht, integriert Jira bereits ein Board auch in Scrum-Projekte), um Minute fuer Minute zu wissen, wie die Arbeit laeuft, und Blockaden zu erkennen, sobald sie auftreten. Und wenn die Produktivitaet nicht wie erwartet ist oder im Laufe der Zeit abnimmt, wuerde ich in Erwaegung ziehen, mehr Kanban- und Scrumban-Elemente einzufuehren.

Kanban

Es ist eine Lean-Methode zur Verbesserung von Arbeitsprozessen, die auf dem Toyota-Produktionssystem basiert. Sie wird oft missverstanden und als Methode zur Arbeitsorganisation verstanden, wobei genau ihre Essenz, naemlich der Teil der Prozessverbesserung, aussen vor gelassen wird.

Sie basiert auf Lean Manufacturing-Ideen, die Just-in-Time-Produktion und die Reduzierung von Verschwendung befuerworten. Ueberproduktion und Defekte gelten als Verschwendung. Um Ueberproduktion zu vermeiden, wird die laufende Arbeit in verschiedenen Prozessstufen begrenzt, wobei diese angepasst werden, um sicherzustellen, dass die teuerste Stufe immer mit maximaler Kapazitaet arbeitet und so maximale Produktivitaet erzielt wird (sie basiert auf der Theory of Constraints). Um Qualitaet zu gewaehrleisten, werden Validierungs- und Qualitaetskontrollprozesse in den Produktionsprozess selbst einbezogen. Im Fall von Toyota durfte jeder Operator an der Produktionslinie die Produktion stoppen, wenn er ein Problem erkannte, was einen radikalen Wandel in der Funktionsweise von Fabriken und eine Ermaechtigung der Arbeiter darstellte.

Im Gegensatz zu Scrum, das sehr vorschreibend ist, ist Kanban ziemlich minimalistisch und schreibt nur wenige Praktiken vor, wobei es jedem Team die Flexibilitaet laesst, seine optimale Arbeitsweise in seinem Kontext zu finden. Zu seinen Hauptpraktiken gehoeren: die Verwendung eines Boards zur Visualisierung der Arbeit, mit Spalten zur Darstellung der Phasen, die eine Aufgabe durchlaeuft, und mit expliziten WIP-Grenzen (Work-in-Progress) fuer jede Phase. Es wird empfohlen, dass das Board physisch ist; heutzutage ist das schwierig… aber wenn das Team physisch am selben Ort ist, halte ich es fuer interessant, weil es einen Treffpunkt und Sozialisierungsraum schafft, an dem man den Arbeitsfluss sehen und darueber sprechen kann, was mit einem virtuellen Board nicht dasselbe ist. Obwohl es auch so gemacht werden kann, wenn es keine andere Wahl gibt.

Unvollstaendige Kanban-Implementierungen sind haeufig, wie die Verwendung eines Boards zur Arbeitsorganisation, aber ohne WIP-Grenzen zu definieren oder Validierungsrichtlinien fuer verschiedene Phasen explizit zu definieren. Einige der auf dem Markt verfuegbaren Tools, wie Jira, helfen nicht, da standardmaessig keine WIP-Grenzen bei der Erstellung eines neuen Kanban-Projekts festgelegt werden (man muss es ueber die Konfiguration tun). Dies verhindert, den wahren Wert des Tools zur Erkennung von Engpaessen und zur Prozessverbesserung zu erhalten.

Im Folgenden teile ich ein Beispiel eines Boards fuer ein Fotounternehmen, dem ich bei der Implementierung von Kanban geholfen habe. Die oberen Karten sind Prozessrichtlinien, die explizit sind und es dem gesamten Team ermoeglichen, dem Prozess zu folgen, ohne sich auf das Gedaechtnis verlassen zu muessen. Es ermoeglicht auch neuen Personen, den Prozess zu kennen, und alles steht an der Wand.

Kanban-Board-Beispiel. Verwendet in einem Fotounternehmen

Die Hauptidee von Kanban ist es, die Arbeit zu visualisieren und die laufende Arbeit zu begrenzen, mit dem Ziel, Probleme und Blockaden zu erkennen, sobald sie auftreten, Ursachen zu analysieren und sie zu loesen. Und dies zu wiederholen, um den Prozess iterativ zu verbessern.

Im Gegensatz zu Scrum, das ein Push-System ist, bei dem Aufgaben in den Sprint Backlog “geschoben” und waehrend des Sprint Planning einem Teammitglied zugewiesen werden, ist Kanban ein Pull-System, bei dem Aufgaben im Backlog unzugewiesen sind und das Team sie nimmt, wenn es Kapazitaet hat und immer die WIP-Grenzen respektiert. Dies ermoeglicht es auch, den Manager davon zu befreien, jeder Person Aufgaben zuweisen zu muessen. Im Fall des Fotounternehmens, das ich zuvor erwaehnt habe, sagte mir der Manager, dass er nicht mehr von Station zu Station gehen muss, um Aufgaben zu verteilen, sondern die Teammitglieder gehen zum Board und nehmen Aufgaben, wenn sie verfuegbar sind. Es ist Kanbans Idee: “Verwalte den Arbeitsfluss, nicht die Arbeiter.”

Die Vorstellung, dass es eine Methode nur fuer Betriebs- und Wartungsteams ist, entspricht nicht der Realitaet. Bei Microsoft zum Beispiel haben sie mehrere Produktentwicklungsteams wie Xbox und Windows, die mit Kanban arbeiten. Viele dieser Teams vollziehen den Uebergang von Scrum, weil sie sehen, wie der Ueberschuss an Zeremonien des Frameworks zu einem Produktivitaetsrueckgang fuehrt (wie Eric Brechner in seinem Buch berichtet, siehe Referenzen).

Scrumban

Es ist das juengste von allen und vielleicht das am wenigsten bekannte. Es ist ein Hybrid zwischen Scrum und Kanban, der Scrums Fokus auf Projektmanagement und Produktlieferung mit Kanbans Pull-System, Arbeitsfluss-Visualisierung und Prozessverbesserung kombiniert.

Zeremonien und Praktiken sind hauptsaechlich die von Scrum, aber unter Verwendung des Kanban-Boards, auf dem Arbeitsfluss-Phasen, WIP-Grenzen und Richtlinien zur Validierung und zum Uebergang von Aufgaben zwischen Phasen definiert werden.

Eine weitere wichtige Aenderung gegenueber Scrum betrifft die Art der Planung: In Scrum werden User Stories einzeln geschaetzt (normalerweise in Story Points), die Teamkapazitaet fuer den Sprint wird berechnet und diese werden Teammitgliedern zugewiesen, bis die Kapazitaet ausgefuellt ist. In Scrumban hingegen ist es nicht notwendig, alle Aufgaben zu schaetzen, sondern nur eine ungefaehre Berechnung der durchschnittlichen Aufgabengroesse durchzufuehren und die Anzahl der in vorherigen Sprints abgeschlossenen Aufgaben zu verwenden, um das Backlog zu fuellen. Es ist ein wesentlicher Unterschied, da die Schaetzung von User Stories eine ziemlich teure und muehsame Aufgabe in Scrum-Teams ist (diejenigen, die sie erlebt haben, wissen, wovon ich spreche). Ein weiterer Unterschied ist, dass in Scrumban die Planung bei Bedarf durchgefuehrt wird, wenn sich das Backlog leert, im Gegensatz zu Scrum, wo diese zeitlich fixiert sind und oft durchgefuehrt werden, wenn noch viele offene Aufgaben aus dem vorherigen Sprint vorhanden sind.

Die einzige Erfahrung, die ich mit der Arbeit mit Scrumban hatte, war kurz und in einem Team, das es uebernahm, um Sprints flexibler zu gestalten und Scrum-Zeremonien bei Bedarf abzuhalten, mit dem Ziel zu vermeiden, Planung mit viel laufender Arbeit durchzufuehren. Das Problem war, dass wir weder das Kanban-Board uebernahmen noch folglich WIP-Grenzen setzten, sodass wir keine signifikante Produktivitaetsverbesserung sahen. Dies lag daran, dass wir den Uebergang zu Scrumban zu einem Zeitpunkt machten, als wir mit Arbeit ueberlastet waren und Scrum-Barrieren entfernen wollten, aber es fehlte uns, kurz innezuhalten, um Scrumban zu verstehen und es korrekt zu implementieren.

Laut dem Einfuehrer von Scrumban (Corey Ladas) ist dies ein Uebergangs-Framework, und Teams, die es korrekt uebernehmen, werden im Laufe der Zeit sehen, wie viele der Scrum-Ideen nicht mehr nuetzlich sind, und koennen das Framework transzendieren und bei Kanbans Pull-System bleiben.

Persoenlich wuerde ich mich, jetzt da ich das Konzept verstehe und Kanban in Aktion gesehen habe, wenn ich ein Framework fuer ein neues Entwicklungsteam waehlen muesste, das ein Projekt beginnen muss, wahrscheinlich zu Scrumban tendieren. Ich denke, es vereint das Beste aus beiden Welten: Scrum und Kanban. Zusaetzlich dazu, dass es einige der muehsamsten Aspekte von Scrum flexibler macht, wie Schaetzungen und Planung. Und dem Team die Freiheit gibt, seine eigene Arbeitsweise zu definieren.

Fazit TL;DR

In diesem Beitrag habe ich versucht, einige der Ideen der agilen Bewegung und ihre Manifestationen in Frameworks und Methodologien zu ueberpruefen. Natuerlich deckt er nicht alle Ideen oder Konzepte ab, aber ich habe versucht, ihn als Ausgangspunkt dienen zu lassen, um verfuegbare Werkzeuge zu ueberpruefen und zu analysieren und zu verfeinern, wie wir sie in den Unternehmen und Teams verwenden, mit denen wir arbeiten.

Dies sind einige der Punkte, die ich fuer die wichtigsten halte:

Die Einfuehrung einer agilen Methodologie erfordert nicht nur eine Aenderung der Gewohnheiten, sondern auch eine Aenderung der Kultur und Denkweise auf Teamebene, aber auch auf Organisationsebene. Das erneute Lesen der Prinzipien des Agile Manifests kann immer ein guter Ausgangspunkt sein.
Es ist sehr haeufig, unvollstaendige Implementierungen agiler Methodologien zu finden, die deren Wirksamkeit verringern, hauptsaechlich weil sie nicht vollstaendig bekannt sind und oft grundlegende Praktiken und Prinzipien eliminiert oder falsch interpretiert werden.
Die Aenderung der Arbeitsmethodik mitten in einem Projekt kann heikel sein, da jede grosse Prozessaenderung eine Anpassungszeit und eine Schonfrist erfordert, in der die Produktivitaet voruebergehend sinken kann. Wenn wir es in einem Projekt tun, das bereits Verzoegerungen ansammelt, ist es leicht, in die Falle zu tappen, nur den Teil der Methodologie zu implementieren, der die unmittelbare Produktivitaet nicht beeintraechtigt.
Schulungen und Zertifizierungen fuer agile Tools koennen helfen, sich mit Frameworks und Methodologien vertraut zu machen. Aber die Verinnerlichung einer neuen Arbeitsphilosophie und die Aenderung der Denkweise ist ein langsamerer Prozess, der Praxis, Reflexion und erneutes Studium erfordert.
Extreme Programming geht ueber eine Methodologie hinaus und wird besser als Philosophie fuer Programmierer definiert, die sie anleitet, wie man gute Fachleute ist, sich in gesunde Teams organisiert und kontinuierlich Wert an Kunden liefert. Obwohl es derzeit nicht viel verwendet zu werden scheint, bleibt es eine ausgezeichnete Quelle zur Ergaenzung anderer Frameworks.
Waehrend XP mehrere technische Praktiken vorschreibt, tun Scrum, Kanban und Scrumban dies nicht. Aber wenn es etwas Entscheidendes gibt, unabhaengig vom ausgewaehlten Werkzeug, dann ist es, dass wir gut definierte technische Werte, Prinzipien und Praktiken haben muessen, weil es der einzige Weg ist, Qualitaetssoftware zu entwickeln.
Kanban ist keine Art, Arbeit zu organisieren; es ist eine Art, zu visualisieren und zu verbessern, wie wir arbeiten. Dies erfordert eine kontinuierliche Bewertung und Anpassung unserer Arbeitsweise. Kanbans Ergebnis ist ein verfeinerter Arbeitsprozess, der an unser Team angepasst ist.
Manchmal koennen verfuegbare Tools und Plattformen uns zu fehlerhaften oder unvollstaendigen Implementierungen fuehren. Zum Beispiel werden in Jira WIP-Grenzen (Work-in-Progress) nicht bei der Erstellung eines Kanban-Projekts gesetzt, sondern muessen spaeter ueber die Konfiguration eingestellt werden. Daher ist es wichtig, Methodologien zu kennen, bevor man sie implementiert.
Das Kanban-Board ist der Ort, an dem der Arbeitsfluss visualisiert wird und an dem die Mitarbeiter nach Aufgaben suchen. Der Manager muss nicht mehr selbst Aufgaben zuweisen. Der Arbeitsfluss wird verwaltet, nicht die Arbeiter.
Scrumban kombiniert Scrums Art des Arbeitens in Iterationen mit Kanbans Prozessverbesserung. Und es macht die Iterationsdauer und die Schaetzung von User Stories flexibler, unter anderem. Zusaetzlich dazu, dass es dem Team mehr Freiheit als Scrum gibt, seine eigene Arbeitsweise zu definieren.

Als abschliessende Anmerkung: Agile Methodologien und Werkzeuge sind, wie jedes andere von Menschen geschaffene Werkzeug, nicht perfekt und haben ihre Grenzen, die wir erfahren, wenn wir sie in der realen Welt anwenden. Es ist in diesen Situationen, wenn gesunder Menschenverstand und die Rueckkehr zu agilen Werten und Prinzipien es uns ermoeglichen koennen, weiter voranzukommen. Und wir duerfen nie vergessen, dass sie Werkzeuge sind, die den Menschen dienen sollen und nicht umgekehrt. Das Agile Manifest sagte es bereits: Wir schaetzen “Individuen und Interaktionen mehr als Prozesse und Werkzeuge.”

Referenzen

Agile Manifesto

Scrum Guide

Scrum.org

The Essence of Agile Software Development — Martin Fowler Web

Clean Agile Book — Rob. C. Martin

Extreme Programming Explained. Second Edition Book — Kent Beck & Cynthia Andres

Agile Alliance Article on Scrumban — Corey Ladas

Scrumban Book — Essays on Kanban Systems for Lean Software Development (Modus Cooperandi Lean) — Corey Ladas

What is Scrumban? Book — Andrew Stellman

Free Kanban and Scrum Book — Making the most of both — Henrik Kniberg & Mattias Skarin

Agile Project Management with Kanban Book — Eric Brechner

Agile Project Management with Kanban Video — Eric Brechner at Google