3

[Dieser Post erschien zuerst auf Englisch.]

Wir haben schon mal beschrieben wie sich Teams bei uns im Laufe der Zeit verändert haben. Anfangs bedeutete „cross-funktional“ für uns noch: Entwickler, Designer, Product Owner, Scrum Master. Heute sind auch Text-Menschen, Kundenbetreuung und Marketing mit dabei. Je nachdem, welches Ziel ein Team hat.

Außer der Zusammenstellung der Teams hat sich aber noch etwas geändert: Die Art wie Teams entstehen, Leute zwischen ihnen wechseln und wie sich Teams wieder auflösen. (Wir haben keine Manager oder Teamleiter, die das bestimmen würden.)

Die initialen Teams

Dazu vielleicht ein kurzer Flashback wie die ersten cross-funktionalen Teams aus den vorhandenen Silo-Gruppen (Web, Java, Telefonie, …) gebildet wurden: Das war verschieden für die verschiedenen Gruppen und die Erinnerungen sind nur noch verschwommen.

Es war Ende des Winters 2009/10 und für die Design/UX-Gruppe, zu der ich gehörte, lief es so: Tim (CEO) bat Wolf, Malte und mich in einen Raum mit Flipchart. Auf dem Flipchart war eine Tabelle mit 3 Spalten, übertitelt mit Team 1 | Team 2 | Team 3. Tim eröffnete uns, dass wir bald mit Scrum starten würden und wir uns auf die neuen Teams verteilen sollten. Unsere Namen waren die ersten.

In den anderen Gruppen wurde ausgelost oder freiwillige Starter für Team 1 gesucht. Die Enthusiasten fanden sich also überproportional in Team 1 wieder. Damit haben wir dann gestartet.

[Heute würden wir es vermutlich machen wie im Buch „Self-Selecting Teams“ von Sandy Mamoli & David Mole beschrieben.]

Der große Split

Die ersten Teams hatten leider nur ein paar ungestörte Monate. Damals haben wir viele Leute in kurzer Zeit eingestellt und die Teams wurden zu groß. Wir wussten, dass wir die drei Teams splitten mussten, um uns in insgesamt 5 Teams neu zu organisieren. Keines der existierenden Teams wollte sich freiwillig auflösen. In meinem Team haben wir Paare mit gleichem Skillset gebildet und dann eine Münze geworfen, wer im Team bleibt und wer in ein neues Team gehen muss. Die Stimmung war damals ziemlich im Keller.

Geheimer Transfermarkt

Diese fünf Teams blieben dann im Kern über Jahre bestehen. Wenn jemand ein Team verlassen wollte, passierte das unter strengster Geheimhaltung. Denn eine Wechsel-Absicht wurde vom Team als „mag uns nicht“ interpretiert. Darum schaute sich niemand offen um.

Wenn man also wechselwillig war, sprach man oft die Scrum Master an, weil die einen guten Überblick den Bedarf der anderen Teams Bedarf hatten.

Seitdem wir Yammer haben, publizieren wir dort „Offene Stellen“ in Teams. Dadurch ist zumindest die Bedarfsseite öffentlich. Manchmal werben unsere Product Owner, ausgehend von einem Yammer-Post, nach und nach ein komplettes Team zusammen.

Gesetz der zwei Füße

Wir verdanken dem Open Friday, dass auch „ich möchte in ein anderes Team wechseln“ kein großes Problem mehr ist. Am Open Friday, wie bei jedem Open Space, gilt das Gesetz der zwei Füße:

Wenn Du zu irgendeinem Zeitpunkt feststellst, dass Du weder etwas lernst noch etwas beitragen kannst, benutze Deine Füße und geh‘ woanders hin.

Das lässt sich prima auf andere Bereiche übertragen! Zum Beispiel, Du ahnst es schon, auf Teamzugehörigkeit 🙂

Wenn jemand das Gefühl hat, dass sich die Aufgaben des Teams dauerhaft verschoben haben und die eigenen Fähigkeiten und Vorlieben nicht mehr gut dazu passen, werden die anderen Teams beäugt.

Wenn man dann wirklich wechseln will, verkündet man das immer noch nicht per Lautsprecher, aber es ist auch nicht mehr Stillschweigen angesagt. Auch klopft man meist direkt beim anvisierten Team an und benutzt keine Mittelsmänner mehr.

Von Teams zu Pools

Inzwischen gibt es eine Tendenz weg von Teams und hin zu „Pools“ von Leuten, die sich um dasselbe Produkt kümmern. Ein „Pool“ besteht aus mehr Personen als normalerweise in einem Team wären. Diese teilen sich je nach anfallenden Aufgaben für kurze Zeiträume (wenige Wochen) in Unterteams auf. Sind sie mit ihren Aufgaben fertig, werden die Unterteams innerhalb des Pools wieder neu gemischt. Diese neue Entwicklung läuft bisher gut und findet Nachahmer. Wir werden sehen 🙂

3 Kommentare

Und wie ist das mit unliebsamen Aufgaben von Kloputzen über Chaos bei den Buchungen beseitigen bis hin zu Kündigen der Fehleinstellung? Drücken sich bei dem System da nicht alle erfolgreich drum?

Hi Bebbi!
Putzen tut ein externes Putzteam, das entfällt also.
Bei den beiden anderen Sachen (Buchungschaos, Kündigen) gilt Verursacherprinzip. Es gibt wenig Leute, die sich davor drücken würden, etwas gerade zu biegen, was sie selbst mit verbockt haben.

Selbst wenn, ein Teamwechsel dauert ein bisschen. Wenn man als Team eine unliebsame Aufgabe bekommt, kann man als Einzelperson nicht direkt in ein anderes Team wechseln, höchstens langfristig. Meistens powert man einfach durch. Dann ist das unliebsame Thema schnell geschafft und man kann wieder was Netteres machen. Was „unliebsam“ ist, ist ja auch eine Typfrage. Es gibt fast immer wackere Recken und Reckinnen, die sich auch unangenehme Themen ziehen und lösen.

Hallo, ich arbeite in einem Coworking Space. Dort haben wir im Schnitt einmal im Monat ein Community Frühstück. Sozusagen auch ein Pool von Leuten. Da kann man seine Projekte vorstellen. So finden sich Leute die vorher nicht miteinander zusammen gearbeitet haben zu einzelnen Projekten zusammen. Soll es mal schneller gehen gibt es eine hausinterne Slack Community Gruppe über die man eigene Projekte vorstellen und Mitstreiter gewinnen kann. Sind die Projekte abgeschlossen widmet man sich seinen eigenen oder neuen Aufgaben.

Dadurch, dass es immer einen Projektinitiator gibt hat auch immer einer den Hut auf. Wie schaut das bei Euren Pools aus? Gibt es da auch je Pool einen Koordinator? Und wenn ja ist der fest oder rotiert er?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*