Es gibt kein Patentrezept für die Auswahl eines agilen Frameworks für dein agiles Team. Egal, ob du Kanban, Scrum oder eine Kombination der beiden Methoden wie Scrumban oder Kanplan anwendest – Agile ist ein Teamprozess. Jedes Team muss selbst herausfinden, welches Framework als Grundlage für die Planung, die Nachverfolgung und die Veröffentlichung erstklassiger Software für die individuellen Anforderungen am besten geeignet ist.
Scrumban vs. Kanban vs. Scrum
Das Ziel von Kanban ist, dass die Teammitglieder gerade so viele Aufgaben haben, dass sie durchgehend ihrer Kapazität entsprechend arbeiten. Teams, die Kanban anwenden, profitieren von der flexiblen Planung, einem klareren Fokus und vollständiger Transparenz, da alles, was sich auf dem Board befindet, oberste Priorität hat. Denn daran arbeiten die Entwickler momentan. Kanban eignet sich hervorragend für operative Teams, deren Fokus auf Continuous Delivery mit wechselnden Prioritäten liegt.
Bei Scrum dagegen werden die Aufgaben in eine Reihe von Iterationen mit fester Länge eingeteilt – die Sprints. Die für einen Sprint geplanten Aufgaben sind die oberste Priorität des Teams (z. B. ein bestimmtes Feature oder eine Gruppe von Features). In der Regel profitieren Produktteams mit einer klaren Roadmap und priorisierten Aufgabenteilen am meisten von Scrum.
Aber vielleicht wäre für dein Team eine Kombination aus Scrum und Kanban am vorteilhaftesten? Oder es möchte von Scrum zu Kanban wechseln? Wenn dies auf dein Team zutrifft, ist die Lösung für dich Scrumban. Diese gemischte Methodologie hat verschiedene Erscheinungsformen, aber am häufigsten nutzen Scrumban-Teams Sprints mit einem Backlog von Scrum und WIP-Grenzen sowie Durchlaufzeiten von Kanban. (Anmerkung: Die Durchlaufzeit ist die Zeit, die eine Arbeitseinheit benötigt, um den Workflow des Teams zu durchlaufen.)
Und was ist mit Teams, die nicht iterativ arbeiten, aber trotzdem ein Backlog pflegen möchten? Für diese Teams könnte Kanplan (oder die Aktivierung des Kanban-Backlog-Features) in Jira die Antwort sein.
Was ist Kanplan?
Kanplan ist eine gemischte Methode für die agile Softwareentwicklung. Wie in Scrumban werden Features sowohl von Scrum als auch Kanban kombiniert. Kanplan ist ideal für Teams, die sich die Möglichkeit zur Backlog-Pflege wünschen, aber nicht in Sprints arbeiten möchten.
Kanban ist ein Fundament und kein strenges Framework
Das Build-Entwicklungsteam von Atlassian ist für eine Plattform verantwortlich, die zum Erstellen von Builds sowie zum Testen und Ausliefern von Atlassian-Software genutzt wird. Die Entwickler sind auf eine zuverlässige Infrastruktur und schnelle Continuous Integration (CI) angewiesen. Vor vier Jahren haben wir 21.000 Builds pro Monat erstellt. Heute sind es mehr als 150.000 Builds im Monat.
Diese Fähigkeit zur Skalierung kann dem Teamwachstum, dem Wechsel von Subversion zu Git, automatisierten Tests und einem weniger offensichtlichen Punkt zugeschrieben werden: dem Wechsel von Scrum zu Kanban. Build-Entwicklung passt nicht gut in ein Scrum-Framework (man denke an Ad-hoc-Anfragen, Vorfälle, Arbeit an Innovationen). Deshalb beschloss das Team, Scrumban einzuführen, was sich schnell zu Kanban verwandelte, da das Team nicht gerne mit Sprints arbeitete. Doch auch Kanban war nicht das Wundermittel, das man sich erhofft hatte. Wie viele andere auch, hat das Team sich bemüht, die Methode für sich funktionsfähig zu machen. Sie probierten erst ein Board, dann mehrere Boards, ein Board für das Supportteam, ein Projektaufgabenboard und andere mit jeweils anderen Workflows. Sie hatten jedoch ein großes Problem bei allen Boards: Das "Ödland", wie es ein Teammitglied nannte, ungesichteter Issues, die in den Modus "Bereit zur Bearbeitung" verschoben werden müssen. Sobald sie sich in der Spalte "In Bearbeitung" befanden, lief alles, aber die "Zu erledigen"-Spalte – die Ödlandspalte – war eben genau dies: ein Ödland.
Umwandeln deiner To-do-Liste in ein Backlog
Unser Build-Entwicklungsteam versuchte, seiner langen, ungeordneten To-do-Liste mit täglichen Standup-Meetings und wöchentlichen Planungsmeetings Herr zu werden. Aber eigentlich würden sie viel dringender ein Backlog als noch weitere Meetings benötigen.
Da Kanban Boards normalerweise keine Backlog-Funktion haben, verwenden Produktmanager, Entwicklungsmanager und Teamleiter zur Planung Issues in der ersten Spalte. Mit dem Anwachsen dieser Liste sind die Issues nur noch schwer zu sehen und zu priorisieren. Das Build-Entwicklungsteam unterteilte seine Boards nach den unterschiedlichen Aufgabenbereichen, aber das gemeinsame Team-Board erschlug einen förmlich (endloses Scrollen gehörte zum Alltag).
Anstatt also andere Methoden zur Neuordnung der Teams oder Boards zu suchen oder das Rad komplett neu zu erfinden, beschloss das Jira-Team, in Kanban ein Backlog einzuführen. Das Kanplan-Feature führt ein breitspaltiges Backlog mit Vorgängen in einer Listenanzeige ein. Hierdurch wird das Kanban Board in zwei verschiedene Bildschirme aufgeteilt – das Backlog zur Backlog-Pflege und das Kanban Board für das Entwicklungsteam zur Auswahl und zum Verschieben von Aufgaben entlang der Workflow-Phasen.
Diese Funktion unterscheidet sich nicht vom Backlog eines Scrum Boards in Jira. Wenn du z. B. auf das Backlog-Symbol in der Seitenleiste klickst, wird eine breite Spalte mit den Backlog-Vorgängen angezeigt. Nachdem du dein Backlog gepflegt hast, kannst du Vorgänge per Drag-and-Drop in die nächste Phase des Workflows überführen.
Diese Kombination des Backlog-Bildschirms von Scrum und des Kanban Boards in einem agilen Board funktioniert wir ein Scrum Board-Backlog. Wenn du ein Issue anklickst, erscheint die detaillierte Issue-Anzeige. Durch fokussierte Anzeigen wie der detaillierten Issue-Anzeige ist jedes Teammitglied in der Lage, seine Aufgaben schneller und mit weniger Ablenkungen zu bearbeiten.
Und auch Teams, die nicht nach der Scrum-Methode arbeiten, aber Epics und zuvor festgelegte Versionen zur Ordnung ihrer Releases verwenden, profitieren von Tools aus Scrum Boards, wie z. B. der Issue-Anzeige oder Schnellbearbeitung. Diese einfache, schnelle Bearbeitungsmöglichkeit ermöglicht Produktmanagern, Entwicklungsmanagern und allen anderen, die im Planungsmodus arbeiten, die effiziente Verwaltung von Epics und Versionen.
Möchtest du deinem Kanban Board ein Backlog hinzufügen?
Die folgende Anleitung zeigt dir, wie du ein Backlog in einem Kanban-Projekt nutzen kannst:
Kanplan ist dafür gedacht, dir "das Beste aus beiden Welten" zu bieten, wie ein Kunde so schön gesagt hat. Für eine bessere Planung kannst du Karten auch ohne laufenden Sprint verschieben und Aufgaben in ein Backlog einordnen. Dadurch wird das Ödland beseitigt, das beim Build-Entwicklungsteam entstand, und Kanban-Teams erhalten einen Planungsmodus, der in der Kanban-Welt bisher fehlte. Außerdem eröffnet Kanplan neue Möglichkeiten für Teams, die sich in Kanban, Scrum oder Scrumban nicht wiedererkennen.
Durch die Integration des Planungsmodus in ein Kanban Board können sowohl Einsteiger als auch alte Hasen dieses agile Framework an ihre Arbeitsweise anpassen, anstatt Best Practices zu befolgen, die möglicherweise nicht für ihr Team geeignet sind. Zu Erinnerung: Bei der agilen Entwicklung sind kontinuierliche Verbesserungen wichtiger als Best Practices.
