[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 :)
11 Kommentare
Bebbi:
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?
Corinna:
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.
Torsten:
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?
Corinna:
Hi Torsten!
Die cross-funktionalen Produktteams haben je einen Product Owner, der priorisiert, welche Aufgaben in welcher Reihenfolge erledigt werden sollen. Das ist bei uns die Person, die den Hut auf hat. Er/sie trägt die wirtschaftliche Verantwortung und ist dafür verantwortlich, die Aufgaben nach Kundenwert zu sortieren.
Seit Anfang des Jahres experimentieren wir damit, dass wir uns weniger stark in festen crossfunktionalen Produktteams organisieren, sondern in „Organisationseinheiten“, die wir „Streams“ (die Weiterentwicklung der „Pools“) nennen. Diese Streams sind personell in der Regel etwas größer als ein herkömmliches Produktteam und in dem Stream bilden sich selbstständig und sehr viel flexibler als bisher kleine Teams aus. Engpässe bei Krankheit/Urlaub/selten benötigten Skills gleichen die Stream-Mitglieder auf dem kurzen Dienstweg innerhalb des Streams aus.
Ein solcher Stream erfüllt alle Anforderungen, die für ein Produktteam gelten. Das heißt, alle benötigten Experten sind da drin und es gibt auch hier einen Product Owner, der im Dialog mit den Kollegen bestimmt, was in welcher Reihenfolge gemacht wird. Er/sie hat sozusagen den Hut für den ganzen Stream auf.
Die Verantwortungen für das Ergebnis und das Produkt tragen aber alle Mitglieder des Streams für ihr gemeinsames Produkt.
Beantwortet das Deine Frage?
Torsten:
Ja, danke für den Einblick.
Halina Maier:
Hallo, vielen Dank für diesen Beitrag! Die Umsetzung des agilen Arbeitens ist sehr klar und konsequent. Eine Bitte: ich schreibe gerade ein Buch zum Thema Agiles Verkaufen. Dabei geht es um agiles Arbeiten in Vertriebsorganisationen. Ich würde sehr gern Sipgate dazu interviewen. Wäre das möglich? Beste Grüße! Halina Maier
Mitch:
Hallo, mich würde interessieren wie ihr die Streams konkret geschnitten habt?
Beste Grüsse, Mitch
Christian:
Hallo zusammen,
wie werden in euren Teams gemeinsame Entscheidungen getroffen? Habt ihr ein bestimmtes Verfahren welches genutzt wird? Und wie sind eure Erfahrungen damit?
Beste Grüße
Christian
Corinna:
So wie ich Deine Frage verstehe: Nach Produkt. Jedes Team arbeitet nur an einem Produkt. An unserem Flaggschiff sipgate team arbeiten mehrere Teams. Hattest Du die Frage so gemeint?
Corinna:
Auf Englisch habe ich hier darüber geschrieben: http://finding-marbles.com/2017/11/30/how-we-take-decisions-without-managers-and-teamleads/
Kurzfassung:
Das kann jedes Team handhaben wie es will. Faustregeln: Je kleiner das Team, desto eher schafft man Konsens Entscheidungen. Je nach Thema gibt es Leute, die sich dort am besten auskennen und deren Stimme dann mehr Gewicht hat. Wenn es ein allgemeines Thema ist, gibt’s im Zweifelsfall Mehrheitsentscheid. Durch Handzeichen oder eine dieser Methoden: http://wall-skills.com/2015/ways-to-vote/
Dann gibt es Entscheidungen, die Auswirkungen über das Team hinaus haben. Die stimmt man dann in größeren Runden ab, z.B. alle Entwickler in der Dev-Community.
PS: Bei uns benutzen relativ viele Kollegen Handzeichen (http://wall-skills.com/2017/hand-signals-for-discussions-in-large-groups/). So bekommen wir schon während einer Diskussion ein Stimmungsbild.
Christian:
Hallo Corinna,
lieben Dank für deine Links zu euren Entscheidungsfindungen. Sehr spannend. Ein Tip von mir: Die beste Erfahrung um zügig und vor allem konfliktfrei Entscheidungen zu treffen habe ich mit Systemischen Konsensieren gemacht. Messung (z.B. mit Handzeichen) des Widerstandes anstatt der Zustimmung. Die Anzahl der Vorschläge ist dabei irrelevant, da jeder Vorschlag einzeln bewertet wird. Aus dem Ergebnis lässt sich Konfliktpotential ablesen. Entschieden wird sich dann für die Alternative mit dem geringsten Widerstand, was im Umkehrschluss die größte Akzeptanz bedeutet.
Bei Interesse gerne mail an mich.
Grüße
Christian