Kanrum²

Kanrum² – ein skalierbares agiles Softwareentwicklungskonzept basierend auf Kanban mit Scrum-Elementen

Wer kennt das nicht? Der Sprint ist minutiös geplant und gerade gestartet. Und schon kommt das Vertriebsteam und/oder der Key-Accounter mit der Forderung, dass dieses oder jenes Feature unbedingt noch in diesem Sprint umgesetzt werden muss, da der Kunde sonst nicht unterschreibt oder die Zahlung verweigert. Gerade Start-Ups können es sich hier oft nicht leisten, „Nein“ zu sagen. Leider wird das dann zur Gewohnheit 🙁

Wenn wir aber ständig und regelmäßig, um nicht zu sagen gewohnheitsmäßig, die (Scrum-)Regeln brechen, dann haben wir de facto keine (Scrum-)Regeln mehr.

Es muss also ein Regelwerk definiert werden, das einige durchaus sinnvolle Elemente von Scrum beibehält, es aber dem Product Owner jederzeit ermöglicht, eine Anforderung hoch zu priorisieren und damit schnellstmöglich umsetzen zu lassen. Etwas, was mit Kanban nahezu uneingeschränkt möglich ist.

Nicht selten sind aber auch mehrere Teams involviert, die unter Umständen sogar an der gleichen Codebasis arbeiten (müssen). Auch diese gilt es zu koordinieren und aufeinander abzustimmen.

Daher ist ein neues Regelwerk erforderlich.

Anforderungen an ein neues Regelwerk

Das Regelwerk muss folgende Anforderungen erfüllen:

• Neue, dringende Anforderungen sollen möglichst rasch (und regelkonform) in den Entwicklungsprozess eingebracht werden können.
• Auf veränderte Prioritäten soll schnell und regelkonform reagiert werden können.
• Eine periodische Präsentation soll weiterhin im Prozess abgebildet werden.
• Das Regelwerk muss auch die Zusammenarbeit mehrerer Teams an der gleichen Codebasis regeln.

Die Idee

Die erste Idee ist Scrumban (für mehrere Teams):
D.h. Ergänzung von Scrum mit Kanban-Elementen (siehe hier zu auch https://www.developmentthatpays.com)

1. Visualisierung in einem Kanban-Board
   – Die meisten Scrum Teams, die mit Jira arbeiten, tun dies bereits. ✅
2. Keine Zuweisung von Tickets zu Entwicklern bereits im Planning
   – Dies wird meines Wissens in den wenigsten Scrum Teams gemacht. ✅
3. Einführung von expliziten WIP-Limits (Work-In-Progress Limits)
   – Dies ist ein Konstrukt aus Kanban => NEU!!
4. Stringentes, visualisiertes Pull-Prinzip
   – Meines Wissens nach wenden die meisten Scrum Teams dieses Prinzip implizit an, visualisieren es aber in der Regel nicht. Die Visualisierung ist aber für die Anwendung von WIP-Limits notwendig!
5. Explizite Priorisierung (Reihenfolge festlegen)
   – Die Priorisierung innerhalb eines Scrum Sprints liegt in der alleinigen Verantwortung des Entwicklungsteams – da hier „nur“ das Ziel „Fertigstellung bis zum Ende des Sprints“ erreicht werden muss => Explizite Priorisierung NEU!!
6. Estimation durch explizites Refinement ergänzen, ggf. ersetzen
   – In Scrum ist das Refinement die notwendige Grundlage für die Estimation, die für die (Kapazitäts-) Planung des nächsten Sprints benötigt wird. Jetzt ist die Gewichtung umgekehrt: Das Refinement ist das Wichtige, die Estimation ist „nur“ ein mögliches Indiz dafür, dass das Refinement die Anforderung ausreichend detailliert hat.
7. Kontinuierliche Entwicklung statt periodischer
   – Die größte Änderung gegenüber Scrum – Das bedeutet aber auch, dass die Planung nicht mehr strikt periodisch erfolgen muss, sondern nach Bedarf (Pull-Prinzip).

Die Punkte 5., 6. und 7. brechen jedoch mit Scrum, so dass es sich eher um Kanban mit Scrum-Elementen handelt => “Kanrum”

Eine weitere Herausforderung ist, dass Scrumban eigentlich immer nur für ein Team beschrieben ist – es müssen also auch Methoden für Multi-Team-Scrum entlehnt werden => “Kanrum²”.

Strukturen der Kanrum² Teams

Die Teams sind wie folgt zusammengesetzt:

Pro Team

• 1 Product Owner
• 4-5 Entwickler
• 1-2 UI/UX-Experten
• 1-2 QA-Experten

Dies ist eine typische Zusammensetzung, die je nach frontend-lastigkeit des Projekts variiert, und ob die UI/UX-Experten auch als Frontend-Entwickler eingesetzt werden.

Team übergreifende Rollen in Kanrum²

• Ein Chief Product Owner (CPO)
• Es wird mindestens ein Agile Coach benötigt, der die Prozesse unterstützt und die teamübergreifenden Meetings moderiert. Es ist denkbar, dass ein Agile Coach mehrere Teams oder sogar alle Teams betreut.
• UI/UX-Experten könnten – je nach Situation – teamübergreifend agieren, anstatt pro Team zu arbeiten. Dies würde jedoch andere Herausforderungen in den Prozessen mit sich bringen und wird hier nicht weiter betrachtet.
• Das Gleiche gilt möglicherweise für QA-Experten.

Kanrum² Visualierung in einem (Jira-)Kanban Board

Die Spalten

• Für das Ready-Backlog und die Prioritätenliste (Next) gibt es jeweils eine Spalte.
• Für jeden Arbeitsschritt gibt es eine Spalte und eine weitere Spalte für den Status ‚erledigt‘.

Die Swimlanes

• Jedem Team ist eine eigene Swimlane zugeordnet.
  • Mit eigenen WIPs (Work in Progress Limits) pro Spalte
    • Abhängig von der Team-Kapazität
      • Anfangswert z.B. 2x Anzahl (aktive) Entwickler (aufgerundet)
  • Je nach Teamkapazität sollten Tickets, die länger als die geschätzten Storypoints* in einer Spalte liegen, bevorzugt im Pair-Programming bearbeitet werden. (ggf. werden sie sogar in die Expedite Swimlane verschoben)
  • Wenn geflaggte Tickets den Workflow behindern, sollten sie in das Team-Ready-Backlog verschoben und neu priorisiert werden.
• Für Blocker Issues steht zusätzlich eine teamübergreifende Expedite Swimlane zur Verfügung.
  • Issues in dieser Swimlane müssen von einem Entwickler – unabhängig von der Teamzugehörigkeit – sofort bearbeitet werden (wer genau, ggf. auch als Pair, ist kurzfristig zwischen den Teams abzustimmen).
  • Dafür sollten andere Issues liegen bleiben können, da die Blocker Issues ja auch nicht auf das WIP Limit in der jeweiligen Teamspalte angerechnet werden.
  • Für die Blocker Swimlane werden keine WIP Limits benötigt!

* unter der Annahme, dass grob geschätzt ein Storypoint in etwas einem halben Personentag entspricht

Die Kanrum² Bestandteile

Die Requirements

1. Das Initial Backlog
   Alle neuen Anforderungen entstehen im Initial Backlog.
   In den Assignment Meetings werden die Anforderungen auf die Teams verteilt (und in das jeweilige Team-Backlog verschoben).
2. Die Team-Backlogs
   Aus dem jeweiligen Team-Backlog wählt der Team-PO die nächsten zu refinenden/slicenden Anforderungen aus. Ist eine Anforderung vollständig gesliced, refined (und ggf. estimated), so gilt sie als “ready” und wird in das Ready-Backlog des Teams verschoben.
3. Die Ready-Backlogs der einzelnen Teams
   Aus den Anforderungen des Ready-Backlogs des jeweiligen Teams wählt der Team-PO die zu priorisierenden Anforderungen aus und priorisiert sie in der Prioritätenliste.
4. Die Prioritätenlisten (Next-Spalte) der einzelnen Teams
   Das Ticket mit der höchsten Priorität wird immer als nächstes in der Prioritätenliste bearbeitet.

Design in Progress

Die „Stationen“ des Design In Progress jedes Teams
Im Rahmen des Refinements werden die Design-Anforderungen in ein separates Ticket ausgegliedert und der Implementierungsteil wird als ein oder mehrere separate Tickets erstellt und als durch das Design-Ticket “blockiert” gekennzeichnet.

1. Design
   Anforderungen in der Prioritätenliste (Next), die ein UI/UX Design erfordern, werden zuerst vom Designer des Teams (oder des teamübergreifenden Designteams) bearbeitet. Wenn das Design abgeschlossen ist, wird das Ticket in die Spalte “Design done” verschoben.
2. Fachliche Abnahme
   Die POs (ggf. mit Stakeholdern) nehmen die Tickets aus der Spalte “Design done” und priorisieren sie in der Prioritätenliste (Next) neu, wenn Nachbesserungsbedarf besteht. Ansonsten schließen sie das Ticket und priorisieren die durch dieses Design-Ticket blockierten Umsetzungs-Tickets in der Prioritätenliste (Next).

Eine eigene Swimlane für Design ist nicht (unbedingt) notwendig, da zum einen nur die Spalten „Ready-Backlog“, „Next“ und „Technische Abnahme“ sowohl „UIX-Tickets“ als auch „Nicht-UIX-Tickets“ enthalten können und zum anderen entsprechend nach „UIX-Tickets“ bzw. „Alles außer UIX-Tickets“ gefiltert werden kann.

In Progress

Die In Progress „Stationen“ der einzelnen Teams

1. Development
   Die Entwickler der einzelnen Teams ziehen – ggf. in Absprache mit dem PO – das nächste Ticket aus der Prioritätenliste. Nach Abschluss der Entwicklung wird das Ticket in die Spalte “Development done” verschoben.
2. Code Review (beinhaltet Developer-Testing)
   Für den Code Review werden die Tickets aus der Spalte „Development done“ herausgenommen und nach erfolgreichem Review in die Spalte „Code Review done“ verschoben oder, falls Korrekturen erforderlich sind, zurück in die Spalte „Development“ verschoben.
3. Qualitätssicherung (Testing)
   Die Tester ziehen sich die Tickets aus der Spalte “Code Review done” und verschieben sie, nach erfolgreichem Test, in die Spalte “Testing done” oder bei Nachbesserungsbedarf in die Prioritätenliste (Next) und priorisieren sie dort mit dem PO neu – diese Tickets werden i.d.R. so hoch wie möglich priorisiert und auch direkt dem ursprünglichen Entwickler zugewiesen.
4. Fachliche Abnahme
   Die POs (oder Stakeholder) nehmen die Tickets aus der Spalte “Testing done” und verschieben sie, nach erfolgreicher Abnahme in die Spalte “Fachliche Abnahme done” oder bei Nachbesserungsbedarf in die Prioritätenliste (Next) priorisieren sie dort gemeinsam mit dem PO neu – diese Tickets werden i.d.R. so hoch wie möglich priorisiert und auch direkt dem ursprünglichen Entwickler zugeordnet.

Deployment

Der genaue Ablauf des Deployments hängt von vielen Faktoren ab und wird hier nicht weiter beschrieben. Grundsätzlich sollte alles, was die Akzeptanztests bestanden hat und in ACCEPTANCE-TEST-DONE gelandet ist, jederzeit deployt werden können.

Die Kanrum² Meetings

Die Dailys

In den Dailys tauschen sich die Teams – bzw. die Funktionen teamübergreifend – in maximal 15‑minütigen “Stand-up-Meetings” über den aktuellen Stand der Dinge aus.

• Team-Dailys
  Teilnehmer: Entwickler + UI/UX + QA + Product Owner + Agile Coach/Chief Product Owner
• Funktions-„Dailys“
  (idealerweise jeweils begleitet/moderiert vom Agile Coach) – ggf. nur 1x-2x/Woche
  • UI/UX-Dailys
    Teilnehmer: Spezialisten aller Teams
  • Entwickler-Dailys
    Teilnehmer: mind. 1 Entwickler aus jedem Team
  • PO-Dailys
    Teilnehmer: Product Owners inkl. CPO
  • ggf. Agile-Coaches Daily
    Teilnehmer: bei mehreren Agile Coaches bietet es sich an auch hier ein „Daily“ – ggf. nur 1x-2x/Woche abzuhalten

Die Process Meetings

1. Backlog Assignment
   Teilnehmer: alle POs, inkl. CPO, je ein (senior) Entwickler aus jedem Team, Agile Coach
   Frequenz: Bei Bedarf (mind. wöchentlich):
   Inhalt des Meetings: In den Backlog Assignment Meetings werden die Issues des initialen Backlogs auf die Team-Backlogs verteilt.
2. Refinement-Meetings (pro Team)
   Teilnehmer: Entwickler + UI/UX + QA + Product Owner + Agile Coach/Chief Product Owner
   Frequenz: Bei Bedarf – in der Regel ausgelöst durch Unterschreiten der Mindestanzahl von Issues im Team-Ready-Backlog oder durch Hochpriorisierung eines Tickets auf hohe bis höchste Dringlichkeit
   In den Refinement Meetings werden die Anforderungen/Stories auf Umsetzbarkeit überprüft (sind die Anforderungen AC vollständig und vollständig verstanden?), dabei wird auch geprüft, ob die Stories noch geschnitten werden können (insbesondere UI/UX herausschneiden), ohne die “INVEST”-Regel zu verletzen – und schließlich estimated.

INVEST: (siehe auch https://www.agilealliance.org/glossary/invest/)
“I” ndependent (of all others) – Unabhängig (von allen anderen Stories)
“N” egotiable (not a specific contract for features) – Verhandelbar, soll bedeuten, dass keine starre Lösung vorgeschrieben sein sollte
“V” aluable (or vertical) – Die Umsetzung einer jeden User Story soll für sich eine Wertsteigerung des Produkts darstellen
“E” stimable (to a good approximation) – Die Anforderungen müssen so klar sein, dass der Aufwand für die Umsetzung von den Entwicklern geschätzt werden kann.
“S” mall (so as to fit within an iteration) – Trotzdem sollen die Stories innerhalb eines Sprints (in Scrum Projekten) – bzw. bei Kanrum² möglichst zwischen zwei Presentations fertig gestellt werden kann.
“T” estable (in principle, even if there isn’t a test for it yet) – Auch wenn sie noch verhandelbar sein soll, so sollen für sie trotzdem genügend genaue Akzeptanzkriterien definiert sein, anhand derer klär überprüft werden kann, ob die Anforderungen umgesetzt sind oder nicht.

Die „Sprint Meetings“

Auch wenn es streng genommen keine Sprints mehr gibt, ist es dennoch sinnvoll, bestimmte periodische Meetings aus dem Scrum-Prozess grundsätzlich beizubehalten:

1. Presentation
   Teilnehmer pro Team: Entwickler + Product Owner + Agile Coach/Chief Product Owner + Stakeholders + ggf. Vertreter der anderen Teams
   Frequenz: z.B. 2-wöchentlich – sollte aber nicht seltener als 4-wöchentlich stattfinden
   Inhalt: Präsentation aller Issues / Features, die seit der letzten Präsentation fertig gestellt wurden.
   Anm.: Die Presentation entspricht in etwa dem Sprint-Review in Scrum

Retros

1. Team Retro
   Teilnehmer pro Team: Entwickler + Product Owner + Agile Coach/Chief Product Owner
   Frequenz: 2-wöchentlich – sollte aber nicht seltener als 4-wöchentlich stattfinden
   Inhalt: Vorrangig sollten hier Themen besprochen werden, die die Zusammenarbeit innerhalb des Teams betreffen, sowie ggf. Einflüsse von außen, die die Arbeit beeinträchtigen oder erleichtern. In der Team Retro sollen auch Themen gesammelt werden, die in der teamübergreifendend Retro besprochen werden sollen.
   Inhaltlich entspricht dies der Scrum-Retro.
2. PO Retro
   Teilnehmer: alle POs, inkl. CPO + Agile Coach
   Frequenz: 2-wöchentlich – sollte aber nicht seltener als 4-wöchentlich stattfinden
   Inhalt: Analog zur Retrospektive der Teams nur in Bezug auf die Zusammenarbeit der POs untereinander.
3. Team-Übergreifende Retro
   Teilnehmer: alle POs, inkl. CPO, mind. je ein Dev-Team-Member aus jedem Team, Agile Coach
   Frequenz: 2-wöchentlich, ggf. bei Bedarf
   Inhalt: Sammlung/Austausch zur Teamzusammenarbeit – insbesondere zu teamübergreifenden Themen aus den Team- und PO-Retrospektiven

This post is also available in: Englisch