In einem meiner vergangenen Projekte begegnete ich einer besonderen Situation in Bezug auf die Aufgabenverteilung der vier Scrum Teams. Eines der Teams hatte eine besondere Stellung. Es bereitete die Aufgaben-Domänen für die drei anderen Teams vor und zwar fortlaufend. Eine Vorgehensweise nach Scrum erwiess sich als nicht passend. Das Team arbeitete an einem kontinuierlichen Strom von User Stories für die anderen Teams.

Wir entschieden uns anstatt des Sprint Backlogs ein Kanban-Board einzuführen. Das wurde von den Team Mitgliedern sehr begrüßt. Es war etwas Neues. Auch hatte das Team sich schwer getan mit dem Task Board, wie es bei Scrum zum Einsatz kommt. Nachdem wir etwas Erfahrung gesammelt hatten mit den WIP-Limits konnten wir ganz gut damit umgehen.

Dabei konnten auch aus den Erfahrungen profitieren, die wir bereits aus der ‚Scrum-Zeit‘ gesammelt hatten.

Mit dieser Maßnahme verbesserte sich die Akzeptanz von ‚agile‘ bei den Team-Mitgliedern beträchtlich. Aber auch die anderen Teams, den jetzt waren immer User Storys vorhanden, die ja fortlaufend erzeugt wurden.
Ganz aufgeben wollten wird Scrum aber trotzdem nicht. Wir planten deshalb auch Retros ein, nicht so regelmäßig wie bei Scrum, aber es gab auch hier Bedarf zum Austausch. Kanban sieht das ja explizit vor: kontinuierliche Verbesserung.