Eines der zwölf Prinzipien hinter dem Agilen Manifest lautet „Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams." Letztere sind ein zentraler Bestandteil von agilen Vorgehensweisen und haben nicht nur das Ziel, unterschiedliche Fähigkeiten von Teammitgliedern optimal zu nutzen, sondern auch Motivation, Selbstverantwortung und Commitment ihrer Mitglieder zu erhöhen.
Was bitte ist ein Self-Designing Feature Team Workshop?
Im Rahmen der Vorbereitung des Kickoffs für ein agiles Projekt mit zwei Scrum-Teams stellten wir Scrum Master uns die Frage, wie wir den Beteiligten von Beginn an das Prinzip der Selbstorganisation verdeutlichen können und gleichzeitig beweisen, dass wir es damit ernst meinen.
Während der Scrum-Guide von einem einzelnen Scrum-Team ausgeht, bestehend aus Product Owner, Scrum Master und Entwicklungsteam, das die Produktvision umsetzt, kann ein komplexes Produkt den Einsatz skalierter Vorgehen erfordern. Eine Einführung in drei weit verbreitete Frameworks findet sich HIER. Im betrachteten Fall hatten wir es mit einem Produkt zu tun, das von einem Product Owner verantwortet und durch zwei Entwicklungsteams umgesetzt werden sollte, die jeweils von einem Scrum Master geführt werden sollten.
Die Mitglieder der zukünftigen Entwicklungsteams hatten unterschiedlichste Hintergründe und Werdegänge, kamen aus verschiedenen Unternehmen und waren eine bunte Mischung durch alle Altersklassen. Schnell war klar, dass wir den Teammitgliedern die Chance geben wollten, die Strukturen, in denen gearbeitet werden soll, mitzugestalten, um auf diese Weise nicht nur die Berücksichtigung unterschiedlicher Perspektiven, sondern vor allem die Identifikation aller Beteiligten mit dem Ergebnis zu erreichen. So bedienten wir uns des Konzepts eines „Self-Designing Feature Team Workshops“ (SDFTW). Zugegeben kein Begriff, der einem leicht von der Zunge geht, auch nicht als Abkürzung, aber im Kern ganz einfach: Die Teams organisieren sich selbst und entscheiden über die Teamaufstellung und andere wichtige Rahmenbedingungen.
Als wichtige Faktoren für das Gelingen dieses Vorhabens identifizierten wir im Vorhinein:
- Transparenz über Regeln bzw. Rahmenbedingungen sowie über Skills der Teammitglieder,
- das Sicherstellen einer ausgeglichenen und fairen Diskussion sowie
- Unterstützung durch das Management.
Skills
Zunächst war es notwendig, dass sich alle besser kennenlernten, zum einen in Bezug auf vorhandene Fähigkeiten, zum anderen was persönliche Interessen und Motive anging. Dafür bieten sich verschiedene Methoden an. Beispiele für erfolgreich eingesetzte Methoden sind HIER beschrieben. Mit dem „Market of Skills“ (siehe Lyssa Adkins, Coaching Agile Teams) haben wir besonders gute Erfahrungen gemacht. Insbesondere die Rubrik „Unter der Ladentheke“ half den Teammitgliedern dabei, schnell einen persönlichen Bezug zu anderen herzustellen: Es kamen lustige und verbindende Details über einzelne Personen ans Tageslicht, die dem Team viele Anknüpfungspunkte für weiteres Kennenlernen boten und ein erster wichtiger Schritt in Richtung Teambildung waren.
Rahmenbedingungen
Für die Teamzusammensetzung geltende Regeln und Rahmenbedingungen waren ein weiterer wichtiger Kontext, den die Teammitglieder für eine sinnvolle Diskussion kennen mussten. Relevante Vorgaben waren im Vorhinein zwischen Scrum Mastern, dem Product Owner sowie den Auftraggebern abgestimmt worden und steckten nun den Rahmen ab, in dem das Team sich bewegen konnte. Sie lauteten:
Natürlich hängt die Wahl der Kriterien von der Team- bzw. Organisationsreife ab. Essenziell in Bezug auf diese Art von Rahmenbedingungen ist allerdings, dass sie nicht so eng gesteckt sind, dass die Teammitglieder nur scheinbar einen Entscheidungsspielraum haben und dass jede von ihnen gewählte Struktur mitgetragen wird, solange sie den Rahmenbedingungen entspricht. Ansonsten verkommt das Vorhaben SDFTW schnell zur Farce. Wichtig ist auch, dass ein gemeinsames Verständnis zu den einzelnen Kriterien herrscht. Aus diesem Grund machte es beispielsweise Sinn, noch einmal herauszustellen, was interdisziplinäre Entwicklungsteams im Sinne von Feature Teams ausmacht (siehe less.works).
Es macht durchaus Sinn, dass der Product Owner in diesem Slot noch einmal herausstellt, was ihm/ihr in Bezug auf die Teamaufstellung wichtig ist, sodass die Teammitglieder diese Punkte bei der anschließenden Diskussion berücksichtigen können.
Diskussion
Nachdem der Kontext klar war, konnte die Diskussion der Teammitglieder in spe beginnen. Während wir Scrum Master bis hierhin eine aktive Rolle in der Moderation des Workshops eingenommen hatten, zogen wir uns für diesen Teil bewusst zurück und beschränkten uns auf die Beantwortung von Verständnisfragen und ein abwartendes Leiten der Diskussion. Wir gaben auch keine Timebox vor. Die Teammitglieder sollten so viel Zeit zur Verfügung haben, wie sie für eine einstimmige, von allen getragene Entscheidung benötigten. Die Rahmenbedingungen waren während der ganzen Zeit für alle gut sichtbar, ebenso die Matrix mit den Skills der Teammitglieder, sodass für potenzielle Konstellationen stets ein Abgleich erfolgen konnte.Die Diskussion war nicht sofort in vollem Gange. Es schien so, als müssten sich die Teammitglieder erst einmal daran gewöhnen, dass die Gestaltung der Zusammenarbeitsform und die Entscheidung darüber jetzt bei ihnen lag und nicht von außen vorgegeben wurde. Nach kurzer Schockstarre begann jedoch ein intensiver Austausch von Gedanken und Ideen.
Zunächst versuchte man, sich über den Ansatz und die ausschlaggebenden Kriterien klarzuwerden. Verschiedene Optionen wie z. B. die Erarbeitung von Vorschlägen in Kleingruppen oder die Annäherung über die gegebene Raumsituation wurden diskutiert und verworfen, bevor man sich über das Thema Skills näherte:
- Es wurden Paare von Personen mit dem gleichen Skill gebildet, die man auf die Teams verteilen könnte,
- es wurden Vorzüge und Nachteile der Aufteilung von Skills auf die beiden Teams besprochen,
- es wurde festgestellt, dass es schwierig ist, Personen auf einen einzelnen Skill zu reduzieren, aber auch dass
- Skills alleine kein hinreichendes Kriterium zur Definition einer geeigneten Teamstruktur sind.
Richtig zielführend wurde die Diskussion in dem Augenblick als ein Teammitglied alle Namen auf Klebezettel notierte und so die Möglichkeit entstand, mit potenziellen Teamkonstellationen herumzuspielen bzw. auf Basis weiterer Erkenntnisse und Argumente zu verändern und neu zu diskutieren. Nachdem alle Aspekte, Bedenken und Vorschläge ausgetauscht waren, fand eine geheime Abstimmung statt, in der die Teammitglieder sich für oder gegen die gewählte Struktur aussprechen konnten. So kam es nach etwas mehr als einer Stunde intensiver Diskussion zu einer einstimmigen Entscheidung über die Zusammensetzung der beiden Teams, die von allen mit einem spontanen Applaus gefeiert wurde.
Eine weitere positive Überraschung für die Teams war die Tatsache, dass sie auch die Entscheidung über ihren Scrum Master und ihren Teamraum eigenständig fällen durften. Hierfür verließen die Scrum Master und der Product Owner den Raum, um einen offenen Austausch der Teammitglieder zu ermöglichen.
Fazit
Als Ergebnis kann ein Self-Designing Feature Team Workshop Teambildung im doppelten Sinn erreichen: Auf der einen Seite schafft er Strukturen für eine produktive und fruchtbare Zusammenarbeit, auf der anderen Seite legt er die Grundlage für Teamgeist, Motivation und Commitment. Zudem sendet er ein Signal an alle Beteiligten, dass man es mit der Einführung agiler Methoden und ihrer Prinzipien ernst meint und Dinge anders macht, als man sie schon immer gemacht hat. Entscheidend für das Gelingen sind Managementunterstützung, ein klarer Kontext sowie eine ausgeglichene und faire Diskussion.zurück zur Blogübersicht
Diese Beiträge könnten Sie ebenfalls interessieren
Keinen Beitrag verpassen – viadee Blog abonnieren
.jpg)
