• Das Tringular Team

Scrum, Kanban, Scrumban – Für welche Teams eignen sich diese agilen Methoden und Frameworks?

Agil sein, das heißt anpassungsfähig sein. Beginnt man ein komplexes Projekt, ist meist nicht absehbar, welche Herausforderungen einem in dessen Verlauf begegnen werden. Am Anfang steht oft eine ungefähre Zielvorstellung, die klarer und ausgereifter wird, je weiter das Projekt voranschreitet. Wie ein Bild, das umso schärfer und detailreicher wird, je näher man ihm kommt. Mit dem Voranschreiten des Projekts ergeben sich Notwendigkeiten und Anforderungen, die anfangs noch nicht erkennbar waren. Das heißt, die Rahmenbedingungen des Projektes ändern sich: vielleicht ist der finanzielle Aufwand größer als gedacht, vielleicht muss die Zielgruppe angepasst werden oder es wird nötig, dem entstehendem Produkt ein weiteres Feature hinzuzufügen – die Möglichkeiten sind vielfältig.


Wie? Indem sie


Individuen und Interaktionenvor Prozesse und Werkzeuge, Funktionierende Softwarevor umfassende Dokumentation, Zusammenarbeit mit dem Kundenvor Vertragsverhandlung, und Reagieren auf Veränderungvor das Befolgen eines Plans


stellen.


Diese vier Grundsätze wurden 2001 von Softwareentwicklern formuliert und als Agile Manifesto niedergeschrieben. Agile Methoden wie Scrum und Kanban geben Teams ein Rahmenwerk zur Implementierung dieser Grundsätze. Sie werden aber nur dann einen Mehrwert für das Team und das Unternehmen haben, insofern sie tatsächlich gewollt sind.


Insbesondere bei Scrum hängt der Erfolg der Methode von ihrem konsequenten Einsatz ab. Es sollte daher im Unternehmen zuerst ein Bewusstsein für die Notwendigkeit und die Vorteile agilen Prozessmanagements geschaffen werden. Deswegen ist es notwendig, die Teammitglieder zu schulen: in einem Scrum-Team sollten nicht nur alle ihre Rolle kennen und verstehen, sondern auch gewillt sein, die Scrum Regeln zu befolgen – ansonsten wird das System als solches nicht funktionieren. Darüber hinaus muss die Unternehmensführung bereit sein, die Mitarbeiter eigenverantwortlich und selbstorganisierend arbeiten zu lassen. Das heißt, es ist wichtig als Chef genügend Vertrauen in das eigene Team haben und die Kontrolle ein (ganzes) Stück weit abzugeben.


„Man darf sich seine agile Methode auch agil zurechtbiegen.“

Auch im agilen Prozessmanagement gibt es keine Patentlösungen. Für effektive Veränderungen muss die Methode an das Team angepasst werden, nicht das Team an die Methode. Grundsätzlich gilt: das Development-Team innerhalb eines Scrum Teams besteht bereits aus 3-9 Leuten. Ist das gesamte Team kleiner, ist es für Scrum nicht geeignet; ist es größer, sollte es gesplittet werden. Wenn mehrere Scrum Teams gebildet werden, ist es notwendig, dass alle Teams dennoch an einem gemeinsamen Product Backlog arbeiten und auch eine gemeinsame Definition davon haben, wann ein Inkrement fertiggestellt („Done“) ist. Dabei handelt es sich um eine potenziell einsatzfähige Version des Produktes, welche Kunden bzw. Anwendern zur Verfügung gestellt werden könnte.


Bei der Entscheidung zwischen Scrum und Kanban kommt es vor allem auf die Komplexität der Aufgabenstellung an. Hat man noch kein klares Ziel und bewegt sich in einem schnelllebigen Markt, in dem langfristige Planung schwierig bis unmöglich ist – dann ist Scrum die richtige Methode. Das liegt vor allem daran, dass Scrum in einem getakteten Entwicklungsrhythmus operiert: es gibt keinen langgezogenen, linearen Entwicklungs-Marathon, an dessen Ende das Team feststellt, dass es auf das falsche Ziel hingearbeitet hat. Stattdessen werden intensive Sprints – kurze Zeitabschnitte mit regelmäßigen Zwischenzielen – genutzt, um innezuhalten, sich zu besprechen, auf die Karte, die Roadmap, zu gucken und gegebenenfalls in eine andere Richtung zu laufen.


Kanban dagegen kann nicht nur von Teams, sondern auch von Einzelpersonen angewendet werden. Bei dieser Methode wird der Arbeitsprozess visualisiert und so effizienter gestaltet. Ziel ist es, die einzelnen Aufgaben flüssig über das Kanban Board zu bewegen und so unnötige Produktivitätslücken zu vermeiden. Der Fluss ergibt sich aus der Visualisierung der einzelnen Aufgaben und dem Vermeiden von individuellem Multitasking. Gerade Teams, die administrative, und daher wiederkehrende, Aufgaben ausführen, also in Sektoren wie Personalmanagement, Kundenservice oder Buchhaltung arbeiten, profitieren von Kanban.

Es ist grundsätzlich auch möglich beide Methoden zu kombinieren: so kann zum Beispiel ein einzelnes Mitglied des Scrum-Teams seine persönlichen Aufgaben über ein Kanban Board visualisieren und strukturieren.


Letztendlich gilt: die richtige Methode findet man über Probieren. Aus einem agilen Mindset heraus handeln, heißt akzeptieren, dass man nicht von Beginn an alle Antworten haben muss und stattdessen mit dem arbeiten darf, was man hat, um so neue Antworten zu finden – und neue Fragen.



Ein bisschen Hintergrund


Scrum

Scrum soll Menschen in die Lage versetzen, komplexe Aufgaben zu bearbeiten und Produkte mit dem höchstmöglichen Wert zu entwickeln. Das Rahmenwerk kommt aus dem IT-Sektor und wird seit den 1990er Jahren verwendet um fortlaufend Produkt, Team und Arbeitsumgebung zu verbessern. Es basiert auf drei Ansätzen der empirischen Prozesssteuerung: Transparenz, Überprüfung und Anpassung.



Ein Scrum Team gliedert sich in die Rollen Product Owner, Scrum Master und Entwicklungsteam. Der Product Owner versucht den Wert des Produktes zu optimieren, indem er/sie Grundstrukturen schafft (z.B. durch Anordnen des Product Backlogs). Der Product Owner pflegt die Inhalte des Product Backlogs – Epics, Features, User Storys, Bugs… – und entscheidet über ihre Priorität. Ein Product Backlog ist nie vollständig, es reflektiert lediglich die aktuell bekannten Anforderungen an das Produkt und entwickelt sich im Laufe des Entwicklungsprozesses kontinuierlich weiter.


Das Entwicklungsteam besteht aus Experten, die selbstorganisiert arbeiten und am Ende eines Sprints das aktuelle Produktinkrement übergeben. Das Team ist interdisziplinär aufgebaut, sodass es unabhängig – und damit effizienter und effektiver – arbeiten kann.

Der Scrum Master hat die Aufgabe die Umsetzung von Scrum im Team zu fördern. Er oder sie sorgt dafür, dass alle Team-Mitglieder die Regeln und deren Mehrwert verstehen und sich daran orientieren.


Das Scrum Team arbeitet in Sprints– Entwicklungsphasen, die jeweils maximal 4 Wochen dauern, und an deren Ende ein neues Produktinkrement steht. Jeder Sprint beginnt mit einer Sprint-Planungssitzung: in maximal 8 Stunden wird ausgearbeitet, was im Produktinkrement des kommenden Sprints enthalten ist, und wie dieses Ziel erreicht werden soll. Dabei bestimmt das Entwicklungsteam, welche Menge an Product Backlog-Einträgen während des Sprints bearbeitet werden können und nach welcher Vorgehensweise dies geschehen soll. Der resultierende Plan wird im Sprint Backlog festgehalten und während des Sprints vom Entwicklungsteam gepflegt und angepasst.


Während des Sprints findet an jedem Tag zu einem festgelegten Zeitpunkt das Daily Scrum statt – diese Kurzbesprechung ist eine 15-minütige, sogenannte Time Box, in der das Entwicklungsteam die Arbeit der nächsten 24 Stunden plant. Dabei wird auf den Grundsatz der Überprüfung zurückgegriffen: das Team evaluiert die bisherigen Arbeitsergebnisse und erarbeitet dazu die nächsten Arbeitsschritte.


Am Ende eines Sprints steht der Sprint Review, ein Zusammentreffen von Scrum Team und Stakeholdern, um das erarbeitete Produktinkrement zu überprüfen und gegebenenfalls den Product Backlog anzupassen. Dieses Meeting sollte maximal 4 Stunden dauern.

In der direkt daran anschließenden Sprint Retrospektive findet das Scrum Team die Gelegenheit, über den Verlauf des vergangenen Sprints zu reflektieren. Ziel ist es, sowohl Erfolge als auch Verbesserungsmöglichkeiten zu identifizieren, um die Arbeitsweise des Teams kontinuierlich anpassen zu können.


Kanban

Kanban ist eine agile Methode, die Ende der 1940er Jahre aus dem Toyota Production System entstanden ist. Der Begriff Kanban kommt aus dem Japanischen und setzt sich aus „Kan“ für Visualisieren und „Ban“ für Karte oder Tafel zusammen. Obwohl die Vorgehensweise ursprünglich zur dezentralen, flexiblen Steuerung von Produktionsprozessen in der Automobilindustrie eingesetzt wurde, lassen sich Kanban-Prinzipien auch gut auf Softwareentwicklung übertragen.


Der Name ist Programm, denn bei Kanban geht es vor allem darum, Arbeitsprozesse zu visualisieren und so effizienter zu gestalten. Ein größeres Projekt wird in kleinere Arbeitsschritte aufgeteilt, die dann einzeln bearbeitet werden.





Dabei fungiert das Kanban Board als zentrales Werkzeug. Das einfachste Kanban Board ist in drei Spalten aufgeteilt: To Do, In Progress, Done. Die Arbeitsschritte werden auf Karten geschrieben und durchlaufen dann die drei Spalten des Kanban Boards. Je nach Aufgabe besteht die Möglichkeit, weitere Spalten, wie zum Beispiel „Backlog“ oder „On Hold“, hinzuzunehmen.


Teammitglieder können sich so ihre Aufgaben selbst aussuchen und gleichzeitig ihre Kollegen wissen lassen, welche Aufgabe sich bereits in Bearbeitung befindet. Im nächsten Schritt wird die Anzahl der Aufgaben in der „In Progress“-Spalte bewusst limitiert – häufig auf weniger Aufgaben, als das Team Mitglieder hat. So wird individuelles Multitasking vermieden, Zusammenarbeit gefördert und damit die Zeit für die Erfüllung einer einzelnen Aufgabe reduziert. In Daily Stand-Up Meetings kommen die Team Mitglieder zusammen um zu besprechen, woran sie gerade arbeiten, was als nächstes geplant ist und wo eventuelle Hindernisse liegen.


#scrum #kanban #scrumban #agilemanifesto