Das Team und ich werden für eine gewisse Zeit zusammenarbeiten, d.h. für uns beginnt ein neuer Zeitabschnitt. Mit dem Kick-Off definiere ich den Beginn dieser für uns beide wichtige Phase.
Darauf bereite ich mich gründlich vor, indem ich bereits 4-Augen-Gespräche führe mit den Team-Mitgliedern, dem/der PO, dem Management und - wenn möglich - mit den Stakeholders.
Das Kick-off mache ich mit jedem Team, unabhängig davon, ob es neu zusammengestellt wurde oder bereits besteht.
Patrick Lencioni hat die Grundlage der Teamentwicklung in seinem Bestseller 'The five dysfunctions of a team' sehr eindrücklich beschrieben: Vertrauen.
Darauf baut alles auf. Lencioni bezeichnet 'Fehlende Offenheit' als das Gegenteil zum Vertrauen und damit eine der Dysfunktionen bei der Teamentwicklung.
Zu Beginn der Arbeit mit einem Team ist es also wichtig, die Grundlagen für Vertrauen zu schaffen. Wenn man vom Gegenteil ausgeht, dann ist es wichtig offen zu sein und dieses auch zu vermitteln.
Ich halte es für wichtig zu Beginn mit jedem Team-Mitglied ein persönliches Gespräch zu führen.
Der Scrum Prozess ist im Scrum Guide beschrieben und sollte möglichst vollständig implementiert werden. Dazu gehören Meetings, Artefakte und Werte und einiges mehr.
Meine Erfahrung ist, dass Scrum nicht richtig funktioniert, wenn Abstriche am beschriebenen Prozess gemacht werden. Dann heißt es 'Wir machen Scrum, aber ...'.
Die Elemente, die im Scrum Guide beschrieben sind, passen zueinander bzw. sind aufeinander abgestimmt. Deshalb gefährdet das Weglassen eines der wesentlichen Elemente den kompletten Prozess mit ungewissem Ausgang.
"Wenn die Werte Selbstverpflichtung, Mut, Fokus, Offenheit und Respekt durch das Scrum-Team verkörpert und gelebt werden, werden die Scrum-Säulen Transparenz, Überprüfung und Anpassung lebendig und bauen bei allen Beteiligten Vertrauen zueinander auf."
Zitat aus dem Scrum Guide
"Ohne Kommunikation ist alles nichts!" Das ist mein Credo aus 30 Jahren Berufserfahrung.
Deshalb achte ich sehr darauf, dass die Kommunikation zwischen allen Beteiligten funktioniert. Das ist m.E. die Grundvoraussetzung für das Funktionieren der drei Scrum-Säulen Transparenz, Anpassung und Überprüfung.
Meine Erfahrung ist es auch, dass das nicht selbstverständlich ist und dann zu Missverständnissen, Fehlinterpretationen und Misstrauen führt.
Indem die Kommunikation mit dem Kunden sehr eng ist, d.h. der Austausch am besten täglich stattfindet, getreu dem Wert des agilen Manifests entsprechend 'Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung'.
Denn nur dann bekommen wir mit, welche potentiellen Änderungen anstehen. Das entspricht einem weiteren Wert des agilen Manifests: 'Reagieren auf Veränderung steht über dem Befolgen eines Plans'.
Und noch ein Wert des agilen Manifests hat einen entscheidenden Einfluss auf dessen Zufriedenheit: 'Funktionierende Software steht über einer umfassenden Dokumentation' und diese auch zu demonstrieren, d.h. dem Kunden zu zeigen, was wir als Team erreicht haben. Dies zeitnah durchgeführt bietet die Chance, feedback zu bekommen für das, was bislang gemacht wurde. Es bietet aber auch die Möglichkeit mit dem Kunden Lösungsalternativen zu besprechen.
Scrum ist ein iterativer inkrementeller Prozess, d.h. das Scrum Team bewegt sich in kleinen Schritten voran und macht nach jeder Iteration einen Fortschritt. Wohin? Die Vision muss am Anfang klar sein.
Ich habe bereits die fünf Scrum-Werte beschrieben. Einmal habe ich in einem Kick-Off diese zu Beginn dem Team erläutert und es gefragt, welchen Wert es für besonders attraktiv hält und dabei eine interessante Antworten bekommen. Das Team, das sehr von außen getrieben war, nannte 'Fokus' als erstrebenswert, weil es den Wunsch hatte, sich auf eine Arbeit konzentrieren zu können und nicht ständig herausgerissen zu werden. Die Stimmung im Team verbesserte sich wesentlich, nachdem wir uns an diesem Wert ausrichteten.
Während des Sprintens entsteht viel Wissen: Fachwissen, Wissen über Abläufe und Strukturen, Vereinbarungen, methodisches Wissen, Erfahrungen, ToDos, usw.
Es sammelt sich ein Wissensschatz an, der auch anderen zur Verfügung stehen sollte. Deshalb ist der Aufbau eines Wikis sehr wichtig. Mit Atlassian/Confluence® geht es sehr einfach, aber auch mit anderen Tools.
Manche sagen sofort.
Meine Erfahrung ist, dass es doch einiges an Vorbereitung bedarf, um loslegen zu können: Kick-Off, Klärung der Vision, Beschreibung der ersten User Stories, Gestaltung der Meetings, Reaktion auf Bugs in der Produktion, Benutzung von Tools für die Entwicklung, Ablauf des Software-Engineering, Systemlandschaft, User Profiles, Tool für die Continuous Integration und evtl. Continuous Delivery, Aufsetzen des Taskboards, usw.
Möglichweise spezielles Know-How und/oder Vereinbarungen mit Zulieferern, Templates z.B. für SLA-Vereinbarungen, usw.
Kanban ist dann gut, wenn ein kontinuierlicher Strom an Ergebnissen 'produziert' wird. Das WIP-Limit (Work in progress) stellt sicher, dass zu einem Zeitpunkt eine vom Team leistbare Anzahl von Aufgaben erledigt werden kann. Damit wird der Gefahr vorgebeugt, dass das Team vor lauter Bäumen den Wald nicht mehr sieht und sich verzettelt.
Kanban kennt auch das Element der kontinuierlichen Verbesserung, wie Scrum. Damit machen auch Retrospektiven Sinn, obwohl sie in dieser Form nicht explizit vorgegeben werden.
Das Scrum Guide sagt: "Der Kern von Scrum ist ein kleines Team von Menschen. Dieses Team ist sehr flexibel und anpassungsfähig. Diese Stärken wirken weiter zwischen mehreren und vielen Teams und sogar Netzwerken von Teams, die die Arbeit und Ergebnisse von Tausenden von Menschen entwickeln, ausliefern, betreiben und erhalten. Sie arbeiten über durchdachte Entwicklungsarchitekturen und Zielumgebungen für Auslieferungen zusammen."
Sind SAFe®, LeSS®, Nexus® solche durchdachte Entwicklungsarchitekturen oder können sich die Teams eine eigene Entwicklungsarchitektur 'erdenken'? Ich denke schon. Ich wage zu behaupten, sie wird den Bedürfnissen der Teams gerechter, weil sie von den Teams selbst kommen.