Team-Kickoff: Der Beginn eines erfolgreichen Scrum-Projekts

Bevor es losgeht

Bevor neue Teams in den ersten Sprint starten, führen wir mit den Teams eine Auftaktveranstaltung durch. Wir sprechen mit Scrum Master:in und Product Owner:in über die Inhalte, die unserer Meinung nach im Voraus geklärt werden sollten, damit das Team erfolgreich loslegen kann. Wir empfehlen, zwei Tage zu investieren, in denen sich das Team kennen lernt und wichtige Inhalte bespricht. Der:die Scrum Master:in bereitet die Veranstaltung vor und führt auch durch das Programm. Anwesend sind das Scrum Team und ggf. ein Coach.

Kennenlernen Teil 1 - Fachliche Skills

Die Gruppe von Menschen, die zu einem Team werden soll, muss sich kennenlernen. Die Fähigkeiten der Teammitglieder sind aus zwei Gründen ein guter Einstiegspunkt: Es ist wichtig, die Skills der anderen zu kennen und es ist ein unverfängliches Gesprächsthema. So kommen alle schnell ins Gespräch, haben etwas zu erzählen und gewinnen einen ersten Eindruck.

Eine Übersicht in Matrixform bietet sich an, gerne mit Klebezetteln an der Wand:

Alle tragen ein

• was sie gern beisteuern wollen (grüner Haken),
• was sie zwar beherrschen, aber nur, wenn notwendig, tun wollen (gelber Kreis),
• wohin sie sich gern im Projekt entwickeln wollen (blauer Pfeil).

Die Skills in den Spalten kann der:die Scrum Master:in vorbereiten, sie können vor Ort ergänzt oder von Grund auf gemeinsam entwickelt werden.

Aus der Matrix kann man Hinweise auf Flaschenhälse, Ausbildungsmaßnahmen, Kopfmonopole und intrinsische Motivation entnehmen. Unser Beispielteam läuft Gefahr, dass die Oberflächen zu Beginn nicht so hübsch werden, aber der:die Scrum Master:in hat sicher schon die Fortbildung für Robert und Max auf den Weg gebracht.

 

Seminarangebot: Scrum Master:in Advanced

Unser Seminarangebot orientiert sich an den Skills, die Scrum Master:innen tatsächlich in der Praxis benötigen.

Werde Scrum Master:in Advanced

Kennenlernen Teil 2 - Unter der Ladentheke

Der erste Einstieg ist geschafft. Die Zusammenarbeit in Scrum Teams ist intensiv und hoffentlich nicht nur kurzfristig. Wir finden es daher sehr wichtig, dass sich die Menschen tiefer kennen lernen. Private Einblicke sind in vielerlei Hinsicht wertvoll:

• Sie schaffen ein besseres Verständnis für die anderen Personen im Team.
• Sie ermöglichen die Entdeckung von Gemeinsamkeiten.
• Menschen die von Hobbys berichten, reden über Tätigkeiten, bei denen sie komplett intrinsisch motiviert sind. Sie zeigen Begeisterung.
• Sie legen die Grundlage für ein Wir-Gefühl (Insiderwitze, Teamsprache, Umgangston).

Wie lassen sich die außerberuflichen Dinge zur Sprache bringen? Im „Market of Skills“ (siehe Lyssa Adkins, Coaching Agile Teams) lässt sich Berufliches und Privates verbinden.

Für Auflockerung sorgt auch folgende Aufgabe: Alle erzählen zwei (möglichst beeindruckende) Wahrheiten und eine Lüge über sich selbst. Die anderen müssen raten, was gelogen war.

Motivation und Erwartungen

Beim Start eines neuen Teams herrscht naturgemäß viel Unsicherheit. Gleichzeitig soll die Startphase möglichst schnell überwunden werden. Wir geben der Transparenz gerne einen möglichst großen Vorsprung. Die folgenden Informationen kann man entweder mühsam im Zeitverlauf erhalten und Stück für Stück zu einem Bild zusammensetzen oder man fragt einfach direkt zu Beginn danach:

• Was erhoffen sich die Beteiligten von der bevorstehenden Aufgabe, welches Ziel verfolgen sie, warum sind sie hier?
• Was motiviert sie mitzumachen?
• Wie sind die gegenseitigen Erwartungen der drei Rollen? Welche Erwartungen davon sind realistisch, welche sind unrealistisch?

Alle machen mit – auch Product Owner:in und Scrum Master:in. Aufgepasst! Diese Fragen sind oftmals nicht einfach zu beantworten. Deswegen sollte der:die Scrum Master:in genug Zeit dafür einräumen, dass alle zu einem Ergebnis kommen. Das Resultat wird dann aber auch eingefordert – kneifen gibt’s nicht.

Teamkodex

Für das Miteinander in der nächsten Zeit soll das Team gemeinsam einen Kodex erstellen, an den es sich halten will. Wir verstehen unter einem Kodex eine Sammlung an Werten (z. B. Offenheit und Respekt) und Regeln (z. B. „Wir lassen uns gegenseitig ausreden.“). Der Kodex erfüllt folgende Kriterien:

• Alle Teammitglieder haben dazu beigetragen.
• Er wurde von allen ohne Einschränkungen akzeptiert.
• Er gilt für alle Teammitglieder.
• Er ist schriftlich festgehalten.
• Er wird während der Projektarbeit sichtbar im Projektraum (bzw. den Projekträumen) platziert.

Wichtig ist, diesen Teil methodisch so aufzubauen, dass alle Teilnehmenden zum einen unbeeinflusst nachdenken können, welche Werte und Regeln ihnen wichtig sind und, dass es zunächst keine Beschränkung gibt, wie viel Inhalt die Einzelnen beisteuern dürfen. Damit ist nicht gemeint, dass jeder initiale Inhalt von allen akzeptiert werden muss. Es darf eine Diskussion über einzelne Punkte geben und es dürfen auch welche gestrichen werden.

Der Teamkodex darf im Zeitverlauf ergänzt oder reduziert werden. Es gelten dann wieder die oben genannten Kriterien.

Obwohl der Kodex die Grundlage für das Miteinander darstellt, beginnen wir den Tag nicht damit. Gemäß dem Motto „Contact before Contract“ sollen sich die Teammitglieder zunächst grundlegend kennenlernen können, bevor sie einen „Vertrag“ miteinander schließen.

Umgang mit Konflikten

Alle gehen mit guten Vorsätzen ins Projekt und verpflichten sich, einem Kodex zu folgen. Und trotzdem ist eines sicher: Es wird Meinungsverschiedenheiten geben. Der Umgang mit diesen fachlichen oder auch persönlichen Konflikten sollte in einer entspannten Situation gedanklich vorweg genommen werden.

Das bedeutet, bereits im Team-Kick-Off darauf hinzuweisen, das Konflikte entstehen werden und, dass diese gewollt sind. Jeder Konflikt ist eine Chance auf Veränderung und damit auf Verbesserung. Der entscheidende Punkt ist, dass ein Team lernt mit Konflikten umzugehen. Dazu können im Team bereits zu Anfang Grundlagen gelegt werden.

Besprochen werden Fragen wie:

• „Was ist für uns ein Konflikt?“,
• „Wie gehen wir mit Konflikten um?“,
• „Welche Arten von Konflikten gibt es?“,
• „Was kann ich tun, wenn ich einen Konflikt wahrnehme?“,
• „Wann und wie ‚eskaliert‘ ein Konflikt?“,
• „Wie gewährleisten wir, dass wir auf inhaltlicher Ebene diskutieren und nicht persönlich werden?“.

So werden erste Antworten für Scrum Master:in und Teammitglieder erarbeitet, die dann in kritischen Situation eine Orientierung für Konfliktbeteiligte und Außenstehende geben. Häufig ist es so, dass bei Beantwortung der o.g. Fragen ebenfalls noch Inhalte für den Teamkodex identifiziert werden.

Diese können bspw. sein:

• Ich behandle andere so, wie ich selber behandelt werden möchte.
• Ich strebe mehr danach zu verstehen, als verstanden zu werden.
• Ich bin kritisch gegenüber Ideen, nicht gegenüber Personen.

Treffen von Teamentscheidungen

Wichtig aus unserer Sicht ist es ebenfalls, den Punkt Entscheidungsfindung zu thematisieren. Den Modus sollte das Team selbst bestimmen. Denkbar wären Einstimmigkeit, Mehrheitsentscheid oder Delegation nach Themenbereich. Empfehlenswert ist unserer Meinung nach nur die Einstimmigkeit. Weicht man davon ab, sind Situationen denkbar in denen Teammitglieder eine Entscheidung mittragen sollen, die ihnen grundsätzlich widerspricht. Man stelle sich vor, drei von sieben Teammitgliedern sollen um 07:00 Uhr morgens unfreiwillig zum Daily erscheinen.

Eine Orientierung bei Konflikten bietet immer der Teamkodex. Die dort festgehaltenen Werte helfen. Deren Einhaltung können und müssen von jedem Teammitglied eingefordert werden.

Teamidentität - Teamname und -Motto

Ob „A-Team“ oder „Team 1“ – wer keine Lust auf kreative Teamnamen hat, sollte besser keinen Namen verwenden als einen erzwungenen.

Wir erleben Teams, die sich zunächst eher zögerlich dem Thema Teamname widmen und bei denen der Teamname später schließlich doch zur festen Identität geworden ist. Empfehlenswert sind Namen, die dem Produkt zugeordnet werden können oder eine Besonderheit des Teams beschreiben. Als Scrum Master:in gilt es hier nichts zu erzwingen. Manchmal gibt es das richtige Wortspiel zur richtigen Zeit, manchmal kommt als bester Vorschlag „Team Internetportal“. Bleibt die zündende Idee aus, kann man zu einem Zeitpunkt, wo sich alle besser kennen, noch einmal in einer Retro über Teamnamen sprechen.

Konnte sich das Team auf einen klanghaften Teamnamen einigen, gibt es viele Stellen, an denen er Verwendung finden kann:

• Mailverteiler – „TeamPerfectPortal@firma.de“
• Anschreiben – Mails vom Scrum Master:in ans Team
• Türschilder – bei Reviews
• Präsentationsvorlagen – als Fußzeile im Powerpoint
• Einladungen – z. B. zu Market Places oder Produktdemos

Mit dem Teamnamen kann die interne Identität des Teams gestärkt werden. Die Mitglieder können ihn kreativ verwenden. Ein Teamname hilft auch, Marketing in der gesamten Organisation betreiben. Die Menschen werden hellhörig, wenn der Satz „Warst Du beim Review von den ‚Guardians of Geschäftskunden‘?“ fällt.

Das Motto eines Teams hat eine andere Wertigkeit und sollte weniger leicht genommen werden, als der Teamname. Das Motto kann wie eine Art Überschrift für den Teamkodex gesehen werden und sollte unserer Meinung nach die Frage „Wie wollen wir arbeiten?“ für dieses Team beantworten. Hier drei hypothetische Beispiele:

• „Hochwertige Funktionalität für unsere Kund:innen – nach jedem Sprint“
• „Qualität vor Quantität: Im Team und nach Außen.“
• „Wir experimentieren viel, wir scheitern schnell, wir sind langfristig erfolgreich.“

Vision und Ziel

Die Vision ist ein zentrales Element von Scrum und dient der Sinn- und Zweckorientierung des Teams. Es lohnt sich daher eine entsprechende Vorbereitung in die Formulierung und Ausgestaltung der Vision zu stecken. Dabei ist die Formulierung der Vision die eine Sache. Die andere ist die Verkörperung der Vision. Das Lebendigwerden durch die Repräsentation im täglichen Handeln.

In der Praxis haben wir festgestellt, dass eine lebendig und authentisch vorgetragene Vision das Team inspiriert und motiviert. Einen gemeinsamen Geist schafft – denn Worte und Gedanken formen Taten.

Dabei hilft es, wenn im Team-Kick-Off die „ranghöchste“ verfügbare Führungskraft die Vision auf High-Level-Ebene beschreibt. Der Grund ist einfach. In der Regel befindet sich das Unternehmen aktuell in einer Transition, so dass das Denken in Hierarchien und Status noch stark verankert ist. Dementsprechend werden den Worten dieser Person eine signifikante Bedeutung zugesprochen.

Der:die Product Owner:in kann dann im Anschluss „übernehmen“ und Details der Vision erläutern und weitere Einblicke geben. Dazu gehören z.b. identifizierte Aufgabenbereiche (Epics), Struktur des Backlogs aber auch die Kriterien, die definieren wann das Produkt als erfolgreich angesehen wird. Ebenfalls werden bereits bekannte Deadlines (bspw. Start der Messe „ASDF“, Release-Termine, benötigte Zulieferungen) kommuniziert und festgehalten.

Artefakte

Die Definition of Done (DoD) dient als zentrale Qualitätscheckliste für das Team. Bei der Erstellung der DoD können zum ersten Mal die unterschiedlichen Qualitätsverständnisse und -vorstellungen jedes Teammitglieds aufgedeckt und zusammengetragen werden. Hier liegen bereits erste Potenziale für Meinungsverschiedenheiten. Es ist sinnvoll, bereits im Vorfeld über Teamkodex und Konfliktsituation gesprochen zu haben, bevor ein kleinster, gemeinsamer Nenner für die gemeinsamen Qualitätsmaßstäbe definiert wird. Auch bei der DoD gilt, dass diese veränderbar ist und bei Bedarf bspw. im Sprint Planning angepasst werden kann.

Falls nötig kann ebenfalls eine DoR (Definition of Ready) aufgestellt werden um Minimal-Standards für Anforderungen / User Storys fest zu halten. Unserer Erfahrung nach ist dies nicht unbedingt notwendig. Im Laufe des Projektes nimmt das gemeinsame Verständnis zwischen den einzelnen Rollen und Teammitgliedern zu und die Flexibilität im Umgang mit Anforderungen steigt.

Last but not least, wird auf das Scrum Board geschaut. Es ist wichtig zu definieren, ob dieses analog (physikalisch) und/oder digital gepflegt wird als auch welche Spalten es beinhaltet, um den internen Teamprozess bestmöglich abzubilden. Auch hier gilt, dass das Scrum Board veränderbar ist und – sollten sich Arbeitsabläufen ändern – angepasst werden kann.

Events

Die Events sind der organisatorische Rahmen und das stützende Korsett für den Sprint. Es gilt, gemeinsam im Team festzulegen, zu welchen Zeiten das Daily stattfindet, wie lang ein Sprint ist und an welchen Tagen der Sprintwechsel stattfindet.

Für die Zeit des Daily Stand Ups bietet es sich an, dieses entweder möglichst früh am Tag oder kurz vor bzw. nach dem Mittagessen stattfinden zu lassen. Früh am Tag kann es ein „Energizer“ sein. Vor oder nach dem Mittagessen sind gute Zeiten, um den Fokus des Teams nicht zu stören und gleichzeitig einen gemeinsamen verbundenen Anschluss (das Mittagessen) zu haben.

Bei den Sprintwechsel-Tagen empfehlen wir, nicht auf einen Freitag oder Montag zu gehen. Freitags befindet sich der ein oder andere evtl. gedanklich zu schnell im Wochenende und der Montag dient evtl. als verlängerter Anreisetag. Ebenfalls gilt es darüber nachzudenken, ob der Sprintwechsel nicht über zwei Tage gesplittet werden kann. Bspw. Dienstagnachmittag Review und Retro, Mittwochvormittag Sprint Planning. Durch die Nacht dazwischen sind die Teammitglieder ausgeruhter und im Allgemeinen wird der Sprintwechsel als weniger stressig empfunden.

Wichtig: Für alle Events muss die Verbindlichkeit deutlich gemacht werden. Eine Diskussion zur Frage wie „Unter welchen Bedingungen kann ich ein Event absagen?“ hilft. Aus unserer Sicht sollte sich der Grund einer Absage ausschließlich auf private Termine beschränken.

Lesetipp: Unsere Kollegin Claudia Simsek-Graf gibt ihn ihrem Blogposts Tipps für effektive Retros und wir haben bereits eine vierteilige Blogreihe über die vier Evolutionsstufen von Sprint Reviews geschrieben.

Tooling

Es gibt an vielen Stellen die Möglichkeit, Scrum mit Software zu unterstützen. Grundsätzlich muss es beim Team-Kickoff keinen eigenen Agendapunkt geben. Tooling ist ein Querschnittsthema, das auch jeweils bei den anderen Inhalten beschlossen werden kann. Bei der Vorbereitung des Kickoffs bietet es sich aber an, über technische Unterstützung insgesamt nachzudenken.

Bei verteilten Teams ist Softwareunterstützung zwingend notwendig: Dailys können per Videokonferenz, wenn es sein muss auch per Telefon durchgeführt werden. Ein gemeinsamer Blick aufs Scrum Board sollte möglich sein. Video ist besser als Audio: Augenkontakt hilft ungemein dabei, Emotionen abzulesen. Über den Tag hinweg bietet sich ein (wenn möglich immer eingeschaltetes) asynchrones Chattool, sowie ein Videochat an. Telefone sind auch erlaubt.

Sitzt das Team im selben Raum, ist es möglich, das Scrum Board analog zu führen. Man braucht Klebezettel (Storys und Tasks), Malerband (für die Swimlanes) und eine Wand. Mit etwas Kreativität und einer Onlinedruckerei lassen sich für alle Teammitglieder auch individuelle Avatar-Aufkleber erstellen, mit denen dann die Karten den Bearbeiter:innen zugewiesen werden. Warum ein analoges Board? Es ist immer da. Ein einziger Blick reicht, um den aktuellen Arbeitsstand zu erfassen. Außerdem ist es ein geiles Gefühl, den letzten Task einer Story unter den Augen der Teammitglieder von „Qualitätssicherung“ auf „Done“ zu schieben.

In den Bereich der Softwareunterstützung gehört auch der Ort der Dokumentation: Laufwerke, Wiki, Cloudspeicher, etc. Hier muss sicherlich nicht viel diskutiert werden – angesprochen werden sollte das Thema trotzdem. Ggf. wird es ja sogar ein Punkt in der DoD.

Feiern

Nach dem anstrengenden und intensiven Tag hat sich das Team etwas Spaß und Entspannung verdient. Die Abendveranstaltung sollte so gewählt sein, dass sich die Teammitglieder weiter kennenlernen können. Jegliches Event, welches den Austausch und die Kommunikation fördert, ist willkommen. Das kann ein einfacher, gemütlicher Restaurantbesuch, das Bewältigen eines Escape-Rooms oder ein gemeinsamer Kochkurs sein. All diese Abendveranstaltungen wecken den Teamgedanken und bauen Unsicherheit unter den Teammitglieder ab, stärken das Vertrauen zueinander und machen vor allem Spaß!